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PREFACE 


This  is  the  first  update  of  Guide  for  the  Manage¬ 
ment  of  Joint  Service  Programs.  The  update  is  based 
on  comments  and  inputs  from  Joint  Program  Offices, 
Service  Logistics  Commands  and  System 
Commands. 

This  Guide  was  prepared  under  the  sponsorship  of 
the  Joint  Logistics  Commanders  (JLC).  Its  goal  is  to 
provide  newly  assigned  managers  of  joint  programs 
the  benefit  of  some  of  the  hard  earned  lessons 
learned  by  previous  managers  who  have  held  such 
position.  The  Guide  is  limited  to  U.S.  Multi-Service 
programs.  The  Guide  also  describes  the  nature  of 
joint  programs,  how  they  differ  from  single-service 
programs,  which  aspects  of  program  management 
demand  greater  emphasis  than  normally  accorded 
single-Service  Programs,  and  some  of  the  pitfalls  of 
joint  program  management.  It  is  assumed  throughout 
the  Guide  that  the  reader  is  trained  or  experienced  in 
military  program  management.  Thus  there  is  no  at¬ 
tempt  to  teach  program  management.  The  Guide 
simply  offers  advice  in  hope  that  the  newcomers  will 
more  quickly  acclimate  to  the  joint  program  environ¬ 
ment  and  avoid  early  mistakes  that  could  make  their 
job  more  difficult. 

The  material  for  this  Guide  comes  from  a  variety  of 
sources  identified  in  the  footnotes  and  references 
and  from  experience  related  by  joint  service  program 
managers  and  their  staffs.  The  major  changes  to  this 
guide  include  discussion  DEP  SEC  DEF  initiatives 
regarding  the  acquisition  process,  revision  of 
Chapter  4  on  acquisition  strategy,  addition  of  cost 
terms  to  the  Financial  Management  Chapter,  pro¬ 
viding  a  common  thread  of  an  acquisition  strategy 
and  charter  for  the  Advanced  Tactical  Aircraft  Pro¬ 
tection  Systems  (ATAPS),  instructions  for  the  prepa¬ 
ration  of  Joint  Integrated  Logistics  Support  Plans 
(JILSP),  Definition  of  terms  and  a  list  of  Joint  Service 
Programs.  The  drafting  or  update  of  the  chapters 
was  accomplished  by  Colonel  John  Patterson, 
USATCOMA;  Mr.  Ivan  Taylor,  Mr.  Bob  Foley, 
AFLC;  Mr.  L.  P.  Timmeney,  NAVMAT;  Mr.  Hal 
Barton,  AFSC;  John  Fargher,  Lieutenant  Com¬ 
mander  Ed  Wicklander,  DSMC. 

Aside  from  its  usefulness  to  program  managers  of 
joint  programs,  this  Guide  should  be  of  interest  to 
help  to  the  many  other  personnel  involved  in  the 


single-Service  and  international  programs.  It  must  be 
recognized  that  the  material  presented  in  this  Guide 
is  subject  to  change  or  adaptation  as  circumstances 
require  and  experience  demands.  It  is  planned  to 
issue  revised  editions  of  the  Guide  periodically. 
However,  program  managers  and  other  users  of  this 
Guide  must  rely  on  official  documentation  for  de¬ 
tailed  decision-making  and  administration.1 

1.  Shortly  before  the  Joint  Commander  signed  this  guide,  the  Deputy 
Secretary  of  Defense,  Frank  C.  Carlucci  signed  DOD  Directive  5000.1  on 
29  March  1982.  Also,  on  12  April  1982,  the  Under  Secretary  of  Defense, 
Research  and  Engineering,  Richard  D.  DeLauer,  promulgated  by 
memorandum  major  defense  system  acquisition  program  documentation 
format.  Because  of  the  close  proximity  of  these  events,  the  policy  and  re¬ 
quirements  of  these  documents  may  not  be  fully  included  in  this  guide. 
Accordingly,  the  reader  should  seek  additional  guidance  from  these 
source  documents. 
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CHAPTER  I 
Introduction 


Why  Are  You  Reading  This  Guide? 

Chances  are  that  you  anticipate  assignment  to,  or 
have  arrived  in,  a  new  job  which  has  joint  service  ac¬ 
quisition  responsibility. 

If  so,  you  have  probably  researched  the  Depart¬ 
ment  of  Defense  Directives  System  Quarterly  Index1 
and  the  Defense  Acquisition  Regulatory  System 
Index  for  leads  to  guidance  on  the  management  of 
joint  or  multi-service  system  acquisition  programs. 
Alas,  that  search  has  been  futile.  So  this  document, 
Guide  for  the  Management  of  Joint  Service  Pro¬ 
grams,  seems  to  be  the  very  target  of  your  search. 

If  the  guidance  you  seek  is  to  reduce  all  joint  pro¬ 
gram  management  concerns  to  textbook  solutions, 
you  will  be  disappointed.  If  you  seek  a  “Joint  PERT”2 
which  will  lay  out  the  critical  path  from  statement  of 
a  joint  requirement  to  deployment  of  a  short  range, 
air-to-air  “purple  widget,”3  you  will  likewise  be  disap¬ 
pointed.  The  guide  will  not  introduce  any  new  tools 
custom-designed  for  the  multi-service  system  acquisi¬ 
tion  environment.  It  will  not  reduce  the  problems  of 
joint  program  management  to  a  mechanical  level  of 
accomplishment.  It  is  not  a  primer  on  project 
management.  (If  refreshment  in  the  basics  of  pro¬ 
gram  management  is  required,  a  review  of  “Introduc¬ 
tion  to  Military  Program  Management”4  is  recom¬ 
mended.) 

The  guide  does  put  some  of  the  common  program 
management  problems  in  a  joint  service  framework. 
It  presents  some  of  the  problems— and  some  possible 
solutions— which  are  unique  to  joint  program  man¬ 
agement.  It  discusses  some  service-peculiar  ap¬ 
proaches  to  certain  aspects  of  acquisition  manage¬ 
ment  to  help  members  of  a  joint  program  manage¬ 
ment  team  understand  what  their  colleagues  from 
other  services  are  talking  about.  It  highlights  areas  in 
which  joint  programs  require  greater  attention  than, 
or  a  different  approach  from,  single-service  pro¬ 
grams,  alerts  the  joint  program  manager  to  major  dif¬ 
ferences  between  the  services,  and  passes  on  some 
lessons  learned  by  previous  joint  program  managers. 
Most  important,  it  will  assure  the  new  joint  program 
manager  that  he  is  not  the  first  to  experience  the 
joint  program  environment,  and  that  by  learning 
from  his  predecessors  he  can  avoid  many  joint  pro¬ 
gram  problems. 


Intent  of  the  Guide 

The  Guide  presents  the  paramount  concerns  of  a 
joint  program  manager  in  a  logical  sequence.  Some 
of  the  earlier  topics  may  be  part  of  a  program’s 
history  by  the  time  a  program  has  been  initiated  and 
a  program  manager  assigned.  Nevertheless,  they  are 
the  foundation  of  a  joint  program,  and  their  treat¬ 
ment  is  intended  to  assist  in  the  establishment  as  well 
as  in  the  management  of  a  joint  program.  Although 
the  chapter  sequence  is  logical,  the  sequence  does 
not  imply  that  attention  to  the  subjects  of  later 
chapters,  logistics  and  test  and  evaluation,  can  be 
postponed  to  late  in  the  program. 

All  the  aspects  of  acquisition  management  in  a 
joint  service  environment  can  not  be  attacked  by  the 
program  manager  all  the  time  with  all  of  his  atten¬ 
tion.  This  guide  will  have  been  successful  if  the  joint 
program  manager  gains  an  appreciation  of  the  vari¬ 
ety  of  challenges  awaiting  him,  the  diversity  of 
methods  to  meet  those  challenges,  and  the  areas 
where  his  attention  and  innovation  will  be  most  effec¬ 
tive. 

Other  Documents  on 
Joint  Program  Management 

In  1973,  the  Joint  Logistics  Commanders  signed  a 
memorandum  of  agreement  which  was  subsequently 
promulgated  as  a  joint  regulation.5  (A  copy  of  the 
agreement  is  in  Appendix  A.)  That  document,  con¬ 
ceived  almost  a  decade  ago,  sets  forth  principles  of 
joint  program  management  that  continue  to  provide 
a  solid  foundation  to  the  establishment  of  a  joint  pro¬ 
gram  management  office.  It  introduces  the  concept 
of  the  Executive  (sometimes  referred  to  as  Lead)  and 
the  participating  services,  and  establishes  general 
responsibilities  and  authorities  of  both.  It  provides 
for  use  of  Executive  Service  program  management 
procedures  in  areas  where  common  procedures  do 
not  exist,  and  calls  for  Multi-Service  Program 
Charters,  Program  Master  Plans,  and  Joint 
Operating  Procedures  to  be  prepared  as  documen¬ 
tary  instruments  of  joint  program  management.  Use 
of  this  regulation  at  the  inception  of  a  joint  program, 
or  at  the  marriage  of  ongoing  single-service  pro¬ 
grams,  will  provide  a  “leg-up”  to  the  people  respon¬ 
sible  for  initiating  the  joint  effort. 
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The  Variety  of  Joint  Programs 

Joint  programs  display  a  wide  range  of  diversity  in 
their  structures,  sizes,  and  objectives.  Consider  the 
joint  program  types  depicted  in  Figure  1-1  and 
described  in  Table  1-3.  Forming  the  lower  half  of  the 
circle  in  Figure  1-1  are  programs  in  which  there 
exists  but  a  single  program  office.  These  start  with 
S-l,  a  single-service  program  without  joint  interest  or 
participation,  and  progress  counterclockwise 
through  various  organizations  exhibiting  increasing 
interest  and  participation  by  another  service  to  S-6, 
which  is  a  fully  integrated  joint  program  office.  On 
the  top  half  of  the  circle  are  depicted  various  types  of 
programs  in  which  there  are  multiple  program  of¬ 
fices,  usually  at  least  one  in  each  of  the  participating 
services.  These,  starting  with  M-l  and  still  moving 
counterclockwise,  continue  the  progression  of  in¬ 
creasing  individual  service  interest  and  participation 
in  the  program,  but  at  the  same  time  depict  a  general 
decrease  in  the  commonality  of  the  individual  service 
efforts.  At  M-5,  the  progression  has  gone  full  circle; 
the  services  are  conducting  fully  independent  pro¬ 
grams. 

The  scheme  used  in  Figure  1-1  to  illustrate  the 
diversity  of  joint  programs  is  unimportant  in  itself. 
Any  given  program  might  not  fit  exactly  into  one  of 
the  categories.  Indeed,  some  programs  tend  to 
migrate  from  one  category  to  another  during  the  life 
of  the  acquisition  program,  for  example  from  M-5 
during  advanced  development  to  M-l  during 
engineering  development  to  S-2  during  production. 
What  is  important  is  to  understand  that  joint  pro¬ 
grams  are  well  dispersed  among  the  categories  (ex¬ 
cluding  S-l  and  M-5  which  are  not  “joint”).  On  the 
one  hand,  this  diversity  sets  free  a  new  joint  program 
from  the  constraints  of  precedents.  A  joint  program 
can  be  structured  any  way  necessary  to  accomplish 
the  program’s  goals.  On  the  other  hand,  the  base  of 
experience  for  each  type  of  joint  program  is  small, 
and  the  advice  and  direction  a  new  joint  program 
manager  receives  (including  that  provided  in  this 
guide)  might  have  been  formed  from  a  joint  program 
environment  not  at  all  similar  to  his  own. 

Certainly  the  size,  that  is,  the  cost,  of  a  program, 
its  importance,  its  urgency,  and  other  factors  which 
influence  its  visibility,  will  affect  a  joint  program  and 
its  way  of  doing  business.  A  joint  mobile  electric 
power  (portable  generator)  program,  for  instance, 
will  look  different  than  a  joint  cruise  missile  pro¬ 
gram.  The  manager  of  each  program  will  be  influ¬ 
enced  by  different  precepts  even  though  both  may  be 
classified  as  “joint  programs.” 

Most  available  policy  and  procedural  guidance  on 
joint  program  management  has  been  developed  by 


cooperative  work  among  service  organizations  and 
published  as  joint  service  documents,  rather  than 
from  the  Office  of  the  Secretary  of  Defense  (OSD). 
With  the  significant  exception  of  the  joint  regulation 
discussed  above,  these  documents  generally  treat  a 
specific  area  of  joint  program  management  in  detail. 
Most  of  these  joint  service  regulations  and  agree¬ 
ments  are  discussed  in  the  following  chapters  as  ap¬ 
propriate  to  their  subject  matter,  e.g.,  the  Standard 
Integrated  Support  Management  System  (SISMS) 
joint  regulation  is  discussed  in  Chapter  9, 
“Logistics.”  A  list  of  joint  service  documents  which 
specify  common  approaches  to  program  manage¬ 
ment  practices  is  provided  in  Table  1-1. 

Individual  service  program  management  guides  or 
handbooks,  which  might  be  especially  helpful  to  non- 
Executive  Service  members  of  a  joint  program  man¬ 
agement  team,  are  listed  in  Table  1-2. 

A  major  aspect  of  program  management  is  the 
establishment  and  administration  of  contracts.  The 
service-wide  source  of  contracting  guidance  is  the 
Defense  Acquisition  Regulatory  System  (DARS).  The 
DARS  is  discussed  in  Chapter  4,  “Acquisition 
Strategy,”  of  this  guide. 

Footnotes 

1.  Department  of  Defense  Directive  5025.1-1. 

2.  PERT  -  Program  Evaluation  Review  Technique. 

3.  Purple  Widget  -  A  cooperative  effort  among  services  is  often  re¬ 
ferred  to  as  “purple,”  as  in  “purple-suited”— referring  to  the  apparent 
color  of  a  uniform,  whether  it  is  actually  light  or  dark  blue  or  green. 
“Widget”  is  simply  a  familiar  term  used  to  denote  any  piece  of  equipment 
or  implement,  a  modem  adaptation  of  “thingamajig.” 

4  Defense  Systems  Management  College,  “Introduction  to  Military 
Program  Management,”  1969  (rev.  1978),  prepared  by  Logistics  Manage¬ 
ment  Institute,  4701  Sangamore  Road,  Washington,  D.C.  20016. 

5.  Previously  DOD  Directive  5000.1  did  not  address  Joint  Service  Pro¬ 
gram  Management.  This  void  necessitated  the  Joint  Logistics  Com¬ 
manders  memorandum  of  agreement  which  was  subsequently  pro¬ 
mulgated  as  a  joint  regulation  (Joint  Air  Force  Systems  Command/Air 
Force  Logistics  Command/Army  Materiel  Command/Naval  Material 
Command  Regulation,  “Management  of  Multi-Service  Systems/Pro 
jects /Programs,”  AFSC/AFLC  R  800-2,  AMC  R  70-59/NAVMAT1NST 
5000. 10A).  The  29  March  1982  issue  of  DOD  Directive  5000.1  on  Major 
Systems  Acquisition  does  include  policy  direction  on  JointiMulti-Service 
Program  Management.  Because  of  this,  the  Service  regulations  cited 
above  are  being  reviewed  for  possible  cancellation,  but  procedural 
guidance  is  included  herein. 
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Figure  1-1 
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Table  1-1 

JOINT  SERVICE  PROGRAM  MANAGEMENT  DOCUMENTS 


TITLE 

DESIGNATION 

ARMY 

NAVY 

AIR  FORCE 

MARINE  CORPS 

Basic  Policies  and  Principles  for 
Interservice,  Interdepartmental 
and  Interagency  Support 

AR  1-35 

NAVMATINST  4000.38 

AFR  400-27 

NAVMATINST  4000.38 

Configuration  Management 

AR  70-37 

NAVMATI NST  4130. 1A 

AFR  65-3 

NAVMATINST  4130.1A 

Integrated  Logistics  Support 
Implementation  Guide  for  DOD 
Systems  and  Equipment 

TM  38-710 

NAVMAT  P-4000 

AFP  800-7 

N  A  VMC-2644 

Interservice  Formal  School  Training 

AR  351-9 

Cancelled 

AFR  50-18 

MCO  1580.7A 

Joint  Design  to  Cost  Guide 

AMCP  700-6 

NAVMAT  P  5242 

AFR  800  11 

NAVMAT  P-5242 

Management  of  Multi-Service 

Systems,  Programs,  and  Projects 

AMCR  70-59 

NAVMATINST  5000. 10A 

AFSC/AFLC  R  800-2 

NAVMATINST  5000.10A 

Standard  Integrated  Support 
Management  System 

DARCOM  R  700-97 

NAVMATINST  4000.38 

AFSC/AFLC  R  800-24 

MCO  P-4110. IB 

Joint  Service  Automatic  Testing 
Acquisition  Planning  Guide 

DARCOM  P  700-19 

NAVMAT  P-9404 

AFSC/AFLC  P  800-38 

N  AVMC-2719 

Table  1-2 

INDIVIDUAL  SERVICE  PROGRAM  MANAGEMENT  GUIDES 


SERVICE 

TITLE 

DESIGNATION 

DDC*  NO. 

ARMY 

Material  Acquisition  Management  Guide 

None 

ADA  046460 

NAVY 

Ship  Acquisition  Reef  Points 

Project  Managers  Guide 

None 

NAVMAT  P-9494 

Stock  No.  0S18L P3947000 

NPFC 

5801  Tabor  Ave. 

Phila.,  PA  19120 

AIR  FORCE 

A  Guide  for  Program  Management 

A  Guide  for  Management  of  Small  Projects 
Acquisition  Management  Illuminators 
for  System  Program  Offices 

Handbook  for  Managers  of  Small  Programs 
Acquisition  Logistics  Management 

AFSC  Pamphlet  800-3 

Published  by 
"each  Product  Division 

AFLC/AFSC  Pamphlet  800-34 

Not  Available 

Not  Available 

Not  Available 

Not  Available 

MARINE  CORPS 

Project  Officers  Guidebook 

None 

Not  Available 

*Defense  Documentation  Center 
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Table  1-3 

JOINT  PROGRAM  TYPES  AND  CHARACTERISTICS 


Program  Destination 

Characteristics 

S-l 

Single-Service 

Interest 

Single-service  interest;  no  interest  or  participation  by  any  other  service; 
not  a  joint  program 

S-2 

Single-Service 

Manager  (Executive 
Agent) 

Single-service  program;  interest  from  other  service(s)  manifested  by  their 
consumption  or  use  of  end  product;  all  program  direction  and  funding  has 
single  source 

S-3 

Single-Service  PMO 
with  On-Site  Liaison 

Single-service  program;  interest  from  other  Service(s)  manifested  by  their 
designation  of  a  Service  point  of  contact  (POC)  for  maintaining  liaison 

S-4 

Single-Service  PMO 
with  On-Site  Liaison 

Single-service  program;  interest  from  other  service(s)  manifested  by  their 
assignment  of  a  full-time  (PCS)  liaison  officer 

S-5 

Single-Service  PMO 
with  Senior 
Representative 

Single-service  program;  representative(s)  from  other  service(s)  assigned 
to  PMO;  all  authority  and  responsibility  to  program  manager  stems  from 
parent  service,  no  formal  coordination  of  requirements,  charter,  etc. 

S-6 

Fully  Integrated  Joint 
Program  Office  (JPO) 

Multiservice  participation,  integrated  JPO,  staffed  by  all  participating 
services,  directed  by  program  manager  assigned  by  lead  service.  Partici¬ 
pating  services  may  perform  some  program  functions,  but  on  behalf  of 
JPO,  not  for  separate  service  program.  MODEL  JPO 

M-l 

Lead-Service 
Coordinated  Programs 

Programs  exist  in  more  than  one  service;  one  service  PMO  provides  coor¬ 
dination  among  all  programs;  executive  authority  does  not  reside  with 
coordinating  PMO 

M-2 

OSD  Directed 

Programs 

More  than  one  service  has  program  in  the  technical  discipline.  A  lead  serv¬ 
ice  is  not  assigned.  The  objectives  of  the  programs  may  not  be  the  same. 
Direction,  coordination  and/or  standardization  is  executed  not  through  a 
designated  lead  service,  but  by  the  OSD,  either  directly,  or  through  a  PMO 
established  for  the  purpose  and  reporting,  not  to  a  military  service  acquisi¬ 
tion  commander,  but  the  OSD 

M-3 

Confederated 

Programs 

More  than  one  service  has  at  least  one  program  in  the  generic  technical 
area  and  the  end  products  of  which  are  used  in  allied  but  separate  warfare 
areas.  The  PMOs  characteristically  share  technical  information  and 
development  data 

M-4 

Single-Service 
Requirement — Other 
Service  Tasking 

Single  service  has  specific  requirement,  but  acknowledging  that  another 
service  has  preeminent  capability  or  interest  in  execution  of  a  part  of  the 
program  objective,  arranges  for  that  segment  to  be  executed  by  the  other 
service. 

M-5 

Fully  Independent 
Programs 

Although  objectives,  requirements,  and/or  technical  discipline  involved  in 
separate  programs  may  have  commonality,  each  service  has  its  own  pro¬ 
gram  to  develop/acquire  a  system 
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CHAPTER  2 
Joint  Program 
Initiation 


Rationale  for  Joint  Programs 

The  future  promises  an  increasing  number  of  joint 
acquisition  programs.  They  can  squeeze  more  out  of 
austere  research,  development  and  production 
budgets,  simplify  logistics  operations,  and  improve 
combat  capability.  They  are  strongly  supported  and 
encouraged  by  the  Office  of  the  Secretary  of  Defense 
and  the  Congress. 

Yet  few  acquisition  programs  are  joint  from  their 
inception.  Most  are  preceded  by  individual  Service 
efforts,  often  after  much  research  and  development 
have  been  accomplished.  The  reasons  for  advocating 
a  joint  program  are  many  and  varied  but  are  ultimate¬ 
ly  reducible  to  some  operational  or  economic  advan¬ 
tage  to  the  DOD.  Typically,  one  or  more  of  the  fol¬ 
lowing  factors  is  at  work: 

—  Coordination  of  Efforts.  Coordination  reduces 
duplication  of  effort,  improves  exchange  of 
technical  information,  and  channels  individual 
Service  efforts  into  mutually  supporting  pro¬ 
grams. 

—  Interoperability  of  Equipments.  Especially  in 
the  areas  of  command  and  control,  communi¬ 
cations,  and  intelligence,  the  interdependence 
of  air,  ground,  and  naval  forces  necessitates 
joint  definition  and  central  control  of  system 
interfaces. 

—  Reduction  in  Development  Costs.  All  other 
things  being  equal,  one  development  program 
should  be  less  expensive  than  two.  If  the  re¬ 
quirements  of  the  Services  are  compatible, 
and  consolidations  of  programs  does  not  in¬ 
crease  risk  unduly  by  closing  out  alternatives, 
it  makes  sense  to  fund  one  joint  program, 
rather  than  multiple,  single-Service  efforts. 

—  Reduction  in  Production  Costs.  Consolidation 
of  the  Services’  production  requirements 
should  lower  unit  price. 

—  Reduction  in  Logistics  Requirements.  Stan¬ 
dardization  across  Services  offers  potential  for 
both  reducing  support  costs  and  improving  the 
support  provided  to  operating  forces. 

The  Marine  Corps,  having  few  research  and  devel¬ 
opment  resources  of  its  own,  has  traditionally  sought 
to  fulfill  its  materiel  needs  through  multi-Service  ac¬ 
quisition  programs.  Among  the  other  Services,  how¬ 


ever,  few  programs  become  joint  without  some  initia¬ 
tive  by  the  Secretary  of  Defense  or  the  Congress. 

Typically,  the  Under  Secretary  of  Defense  for  Re¬ 
search  and  Engineering  (USDRE)  writes  a  memoran¬ 
dum  designating  one  Service  the  Executive,  or  Lead, 
Service  and  directing  it  to  charter  a  joint  program.  In 
at  least  two  cases,  a  formal  DOD  directive  has  been 
issued.1  Less  formal,  but  no  less  compelling,  direc¬ 
tion  is  given  to  the  Services  during  program  or 
budget  reviews.  The  Services  negotiate  the  ground 
rules  of  the  joint  program  and  agree  to  assignment  of 
program  authority  and  responsibility.  The  implemen¬ 
tation  of  OSD  direction  is  different  in  each  of  the 
Services.  The  Army  and  Navy  simply  forward  by 
memorandum  USDRE’s  direction  to  the  develop¬ 
ment  and  acquisition  activity  specified  in  Table  2-1 
via  the  chain  of  command.  In  the  Air  Force,  HQ 
USAF  directs  major  command  participation,  either 
as  lead  or  supporting  elements,  via  Program  Manage¬ 
ment  Directives  (PMD).  Further  delineation  of  partic¬ 
ipation  below  major  command  level  is  promulgated 
by  Form  56  within  AFSC,  and  Program  Action  Direc¬ 
tive  (PAD)  within  AFLC. 

Inter-Service  Agreement  on 
Joint  Program  Initiation 

Inter-Service  negotiation  and  agreement  on  a  joint 
program  can  be  accomplished  at  any  of  several  eche¬ 
lons  in  the  Services’  organizational  hierarchies:  the 
Service  secretariats,  the  Service  headquarters,  the 
materiel  development  and  logistics  commands,  or 
their  commodity-oriented  subcommands.  Table  2-1 
shows  the  materiel  development  and  acquisition 
organizations  of  the  same  level  in  the  hierarchy,  such 
as  the  Assistant  Secretaries  of  the  Army  and  Navy. 
However,  exceptions  do  occur.  For  example,  the 
Commanders  of  the  Naval  Air  Systems  Command 
and  the  Air  Force  Systems  Command  have  agree¬ 
ments  on  acquisition  of  air-to-air  missiles. 

If  there  is  a  general  rule,  it  is  to  agree  that  the 
lowest  level  agreement  is  practicable,  and  that  varies 
from  program  to  program.  However,  there  are  two 
advantages  to  agreements  at  the  Service  head¬ 
quarters  level:  (1)  it  is  the  level  at  which  operational 
requirements  are  validated  and  translated  into  equip¬ 
ment  needs;  and  (2)  it  is  the  level  at  which  funding 
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Table  2-1 

MILITARY  SERVICES'  ORGANIZATIONS  FOR  MATERIEL 
DEVELOPMENT  AND  ACQUISITION 


ARMY 

AtR  FORCE 

NAVY 

MARINE  CORPS 

Service 

Secretariat 

Assistant  Secretary  of  the  Army 
(Research,  Development  and  Acquisition) 

Assistant  Secretary  ot  the  Air  Force 
(Research,  Development  and  Loqi«tics) 

Assistant  Secretary  ot  the  Navy 

(Research,  E>-(ttneer;ng  a->d  3y-.tfeir.si 

Assistant  Secretary  of  the  Navy 
(Research,  Engineering  and  Systems) 

Service 

Headquarters 

Deputy  Chief  of  Staff  tor  Research, 
Development  and  Acquisition 

Deputy  Chief  ot  Stall  tor  Research, 
Development  and  Acquisition 

Deputy  Chief  of  Naval  Operations 
tor  Research,  Development, 

Test  and  Evaluation 

Deputy  Chief  ot  Staff  for  Research, 
Development  and  Studies 

Deputy  Chief  ot  Statl  for 

Installations  and  Logistics 

Materiel 
Development 
and  Logistics 
Commands 

Department  ot  Army  Materiel 

Development  and  Readiness 

Command 

Air  Force  Systems  Command 

Air  Force  Logistics  Command 

Naval  Material  Command 

Naval  Material  Command 

Army 

Commodity 

Commands 

Air  Force 
Product 
Divisions 
and  Centers 

Navy 

Systems 

Commands 

Research  and  Development  Commands: 

Arma  ment 

Aviation 

Communications 

Electronics 

Mobility  Equipment 

Tank/Automotive 

Readiness  Commands 

Armament 

Communications 

Tank/ Automotive 

Troop  Support 

Research,  Development  and 

Readiness  Commands: 

Missiles 

Systems  Divisions: 

Aeronautical  Systems  Division 

Armament  Division 

Ballistic  Missile  Office 

Electronics  Systems  Division 

Space  Division 

Air  Force  Acquisition  Logistics 

Division 

Air  Logistics  Centers 

Ogden 

Oklahoma  City 

Sacramento 

San  Antonio 

Warner  Robins 

Naval  Air  Systems  Command 

Naval  Electronic  Systems  Command 

Naval  Facilities  Engineering  Command 

Naval  Sea  Systems  Command 

Naval  Supply  Systems  Command 

Marine  Corps  Development  and 

Education  Center 

priorities  are  established.  As  all  joint  program  man¬ 
agers  soon  learn,  nothing  is  more  important  to  the 
success  of  a  joint  program  than  inter-Service  agree¬ 
ment  on  requirements  and  funding.  The  major  dis¬ 
advantage  of  inter-headquarters  agreements  is  that 
staff  consideration  can  take  a  long  time. 

When  agreement  is  reached  at  either  the  Service 
headquarters  or  secretariat  level,  it  is  usually 
documented  by  a  memorandum  of  agreement  (MO A). 
There  is  no  typical  content  or  format  for  a  MOA.  It 
may  be  a  long  document  defining  all  the  ground  rules 
for  the  joint  program,  much  as  would  a  charter.  It 
may  be  very  brief,  covering  only  key  areas  of  agree¬ 
ment,  such  as  designation  of  the  Executive  Service 
and  sharing  of  funding  responsibility.  Frequently  a 
program  will  have  several  MOAs  associated  with  it, 
each  covering  a  different  topic. 

Joint  Program  Charters 

Preparation 

The  charter,  once  promulgated,  is  the  foundation 
of  a  joint  program.  It  establishes  the  program  and  an¬ 
nounces  to  all  concerned  the  responsibility  and 
authority  assigned  to  the  program  manager  and  the 
intended  relationships  among  the  participating  Serv¬ 
ices.  Whenever  possible,  the  prospective  program 
manager  should  take  the  lead  in  shaping  these  as¬ 
signments,  preferably  by  drafting  the  charter  himself. 
An  example  of  a  joint  charter  for  the  ASPJ  is  at¬ 
tached  in  Appendix  B. 


Establishing  the  Program  Manager’s  Authority 

While  the  charter  cannot  guarantee  that  the  joint 
program  manager  will  have  authority  commensurate 
with  his  responsibilities,  care  can  be  taken  to  insure 
that  the  charter  does  not  deny  him  the  authority 
needed  to  manage,  rather  than  merely  to  coordinate 
the  joint  program.  Specifically,  the  program  manager 
must  have  adequate  authority: 

—  to  make  trade-offs  between  cost,  schedule, 
supportability  and  performance  within  bounds 
established  for  the  program 

—  to  identify  program  funding  needs  and  to  con¬ 
trol  funds  allocated  to  the  program 

—  to  determine  and  control  hardware  and  soft¬ 
ware  configuration 

—  to  communicate  directly  with  other  Services 
and  Government  agencies 

—  to  manage  his  military  and  civilian  workforce 

Promulgation 

Charters  for  joint  programs  are  normally  promul¬ 
gated  by  the  Executive  Service.  Although  the  JLC 
“Memorandum  of  Agreement  on  Management  of 
Multi-Service  Systems/Programs/Projects”  calls  for 
joint  approval  of  joint  program  charters,  jointly 
signed  charters  are  rare.  The  program  manager 
should  coordinate  the  charter  with  the  Participating 
Services  at  the  materiel  development  command  or 
Service  headquarters  level  and  try  to  obtain  formal 
concurrence.  However,  it  should  be  anticipated  that 
such  coordination  is  likely  to  take  a  long  time, 
months  rather  than  weeks. 
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For  major  programs,  Army  charters  are  approved 
by  the  Secretary  of  the  Army,  Navy  charters,  Navy 
Acquisition  Executive,  i.e.,  the  ASN  (RE&S)  or  the 
ASN  (S&L)  depending  on  the  nature  of  the  particular 
acquisition,  and  the  Air  Force  program  management 
directives  by  the  Deputy  Chief  of  Staff  (Research, 
Development  and  Acquisition)  or  the  Deputy  Chief  of 
S  .aff  (Logistics  and  Engineering).  For  non-major 
programs,  the  chartering  authority  is  delegated  to 
tiie  materiel  development  or  logistics  commanders 
according  to  specific  Service  practices.  (The  Serv¬ 
ices’  hierarchies  of  non-major  programs  are  illus¬ 
trated  in  Tables  5-2  through  5-5.)  On  a  few  occa¬ 
sions,  program  charters  have  been  promulgated 
directly  by  OSD,  but  that  is  unusual  and  has  occurred 
primarily  when  OSD  wanted  to  coordinate  independ¬ 
ent  Service  programs. 

Contents 

Joint  programs  are  exceptions  to  the  Services’  nor¬ 
mal  acquisition  practices.  Thus,  the  joint  program 
charter  must  include  both  those  elements  essential  to 
any  charter  and  those  needed  to  define  specific  rela¬ 
tionships  between  the  Participating  Services.  The  ex¬ 
tent  to  which  the  latter  must  be  defined  in  the 
charter  depends  on  the  circumstances  surrounding 
establishment  of  the  joint  program.  If,  at  the  inau¬ 
guration  of  a  joint  program,  there  exists  a  major 
issue  involving  responsibility,  authority,  or  inter¬ 
service  relationships,  it  should  be  resolved  in  the 
charter,  or  it  will  haunt  the  program  throughout  its 
life. 

Essential  Elements.  The  following  elements  are  the 
minimum  which  must  be  addressed  in  the  charter: 
—Designation  of  the  joint  program 
—Statement  of  the  program  objective 
—Definition  of  the  program  manager’s  authority, 
responsibility,  and  accountability 
Specification  of  program  resources  and  funding 
agreements 

Definition  of  the  Services’  joint  or  unilateral 
responsibilities  for  program  execution 
—Description  of  the  relationships  of  the  joint  pro¬ 
gram  with  other  programs,  supporting  organiza¬ 
tions,  and  supported  organizations 
— Identification  of  the  chain  of  command  for 
reporting  and  for  resolving  program  issues 
—Reporting  requirements  (type,  format,  and  fre¬ 
quency) 

—Project- office  organization  and  initial  staffing 
—Requirement  to  establish  joint  operating  pro¬ 
cedures  (JOP).  Minimum  contents  may  be 
specified 


Optional  Elements.  The  following  elements  are 
generally  optional,  but  may  be  essential  for  success 
of  some  programs.  In  fact,  writers  should  consider 
making  these  elements  essential.  Since  each  element 
is  a  potential  problem  area,  mandatory  inclusion  will 
eliminate  the  need  for  clarification  at  a  future  time: 
— Assignment  of  the  deputy  program  managers 
from  the  Participating  Services,  definition  of 
their  responsibility  and  authority,  and  designa¬ 
tion  of  their  rating  officials 
—Methods  for  resolving  conflicting  requirements 
or  objectives  of  the  Services  involved 
— Creation  of  joint  committees  for  coordination  or 
approval  of  key  aspects  of  the  program  (e.g.,  re¬ 
quirements,  funding,  source  selection,  test  and 
evaluation  plans,  and  configuration) 

— Performance  evaluation  of  personnel 

Review  and  Update 

As  a  joint  program  progresses  through  the  acquisi¬ 
tion  process,  management  needs  and  the  relation¬ 
ships  of  the  participating  Services  probably  will 
change.  Therefore,  the  joint  program  manager 
should  review  the  charter  periodically,  at  least  an¬ 
nually,  to  ensure  that  its  descriptions  of  program  mis¬ 
sion,  responsibilities  and  authority  of  the  program 
manager,  and  inter-service  relationships  are  still  ac¬ 
curate.  If  not,  the  charter  should  be  revised. 

Footnotes 

1.  Department  of  Defense  Directive  4120.11,  Mobile  Electric  Power 
(MEP)  Generating  Sources:  Standardization  of,  December  14,  1973,  and 
DOD  Directive  5148.7,  Program  Charter,  TR1-TAC. 
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CHAPTER  3 
Joint  Requirements 


No  aspect  of  a  joint  program  is  more  critical  to  the 
program’s  success  than  the  statement  of  operational 
requirements.  It  is  the  cornerstone  of  a  joint  pro¬ 
gram.  The  premise  of  a  joint  program  is  that  there  is 
sufficient  commonality  in  the  services’  requirements 
that  a  joint  effort  will  be  beneficial.  The  challenge  is 
to  develop  a  set  of  requirements  that  will  satisfy  the 
operational  needs  of  all  participating  services  without 
unduly  compromising  individual  service  needs,  im¬ 
posing  parochial  technical  approaches  that  will  ham¬ 
string  the  program,  or  developing  a  product  none  of 
them  can  afford  to  buy. 

Requirements  Documents' 

The  basic  requirements  document  for  a  major  ac¬ 
quisition  program  is  the  Justification  of  Major  Sys¬ 
tems  New  Starts  (JMSNS).  A  JMSNS  identifies  a  spe¬ 
cific  deficiency  in  a  mission  area,  the  priority  as¬ 
signed  to  correcting  the  deficiency,  and  the  magni¬ 
tude  of  resources  needed  to  correct  the  deficiency.  A 
brief  outline  of  a  JMSNS  is  shown  in  Table  3-1.  A 
joint  JMSNS  documents  major  deficiencies  in  two  or 
more  services.  Approval  of  a  JMSNS  is  a  prerequisite 
for  initiation  of  a  major  system  acquisition  program. 

A  JMSNS  is  the  document  upon  which  the  Mile¬ 
stone  0  decision  is  based.  It  identifies  and  defines:  (a) 
a  specific  deficiency  or  opportunity  within  a  mission 
area;  (b)  the  relative  priority  of  the  deficiency  within 
the  mission  area;  (c)  the  Defense  Intelligence  Agency 
(DIA)  validated  threat  forecast  or  other  factor  caus¬ 
ing  the  deficiency;  (d)  the  date  when  the  system  must 
be  fielded  to  meet  the  threat;  and  (e)  the  general 
magnitude  of  acquisition  resources  that  the  DOD 
component  is  willing  to  invest  to  correct  the  deficien¬ 
cy.  A  JMSNS  is  required  for  each  major  acquisition, 
including  system  modifications  and  additional  pro¬ 
curement  of  existing  systems,  which  the  DOD  com¬ 
ponent  anticipates  will  cost  in  excess  of  $200  million 
(FY  1980  dollars)  in  research,  development,  test,  and 
evaluation  (RDT&E)  funds  or  $1  billion  (FY  1980 
dollars)  in  procurement  funds.  A  JMSNS  is  not  re¬ 
quired  for  programs,  regardless  of  size,  directed 
toward  developing  and  maintaining  a  viable  techno¬ 
logy  base.  HQ  USAF  uses  preconceptual  review  to 
determine  if  a  JMSNS  is  needed.  If  the  data  indicates 
a  major  system  acquisition  program  or  Air  Force 


Designated  Acquisition  Program  (AFDAP)  may 
result,  a  JMSNS  is  required.  (Note:  Chapter  11 
covers  in  more  detail  the  changes  which  have  re¬ 
sulted  from  the  DOD  Acquisition  Improvement  Pro¬ 
gram). 

The  deficiency  or  opportunity  identified  in  a 
JMSNS  should  be  defined  as  narrowly  as  possible  to 
allow  a  reasonable  probability  of  correcting  the  defi¬ 
ciency  by  acquiring  a  single  system.  Defining  a  broad 
architecture  of  systems  to  counter  projected  threats 
in  a  mission  area  is  part  of  the  ongoing  analysis  of 
mission  areas  rather  than  a  part  of  a  specific  acquisi¬ 
tion  program.  Though  the  scope  of  the  deficiency 
identified  in  a  JMSNS  shall  be  narrowly  defined,  solu¬ 
tions  to  the  problem  shall  not  be  specified.  Alterna¬ 
tive  concepts  and  associated  risks  shall  be  evaluated 
in  the  Concept  Exploration  phase. 

There  may  yet  remain  some  uncertainties  about 
what  constitutes  a  good  JMSNS  and  whether  the 
JMSNS  will  replace  or  augment  some  of  the  existing 
requirements  documents  in  the  services.  Since  the 
use  of  the  JMSNS  is  restricted  to  major  acquisitions, 
operational  requirements  for  less-than-major  acquisi¬ 
tions  will  probably  continue  to  be  stated  in  service- 
peculiar  requirements  documents  which  tend  to  be 
more  detailed  and  more  weapon-system-oriented 
(vice  mission-oriented)  than  a  JMSNS.  This  same 
practice  is  likely  to  hold  true  for  joint  acquisitions: 
major  •  acquisitions  will  be  supported  by  a  joint 
JMSNS;  less-than-major  acquisition  will  be  supported 
by  a  joint  operational  requirement  (JOR),  or  similar 
document,  which  is  more  detailed  and  more  weapon- 
system-oriented  than  a  JMSNS. 

In  the  Army,  the  JMSNS  is  the  requirements  docu¬ 
ment  only  for  the  conceptual  development  phase  of  a 
program.  A  letter  of  agreement  (LOA)  is  the  require¬ 
ments  document  for  the  demonstration  and  valida¬ 
tion  phase.  A  required  operational  capability  (ROC) 
or  letter  requirement  (LR)  defines  requirements  for 
the  full-scale  engineering  development  phase. 
Primary  responsibility  for  preparing  requirements 
documents  is  assigned  to  the  Training  and  Doctrine 
Command  (TRADOC).  At  Headquarters,  Depart¬ 
ment  of  Army,  the  Deputy  Chief  of  Staff  for  Opera¬ 
tions  and  Plans  (DCSOPS)  has  Army  General  Staff 
responsibility  for  requirements  documents. 
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Table  3-1 

JUSTIFICATION  OF  MAJOR  SYSTEMS  NEW  STARTS 


A  .  MISSION 

1.  Mission  areas 

2.  Mission  element  need 


B  .  THREAT  OR  BASIS  FOR  NEED 

C  .  EXISTING  AND  PLANNED  CAPABILITIES  TO  ACCOMPLISH  THIS  MISSION 

D.  ASSESSMENT  OF  NEED 

1.  Deficiency  in  existing  capability 

2.  Exploitable  technological  opportunity 

3.  Force  size  or  physical  obsolescence  of  equipment 

4.  Vulnerability  of  existing  systems 

E  .  CONSTRAINTS 

1.  Timing  of  need 

2.  Relative  priority  within  mission  area 

3.  Logistics,  safety,  health,  energy  environment,  and  manpower  considerations 

4.  NATO  and  DOD  standardization  and  interoperability 

5.  Potentially  critical  interdependencies  or  interfaces 

6.  Industrial  base  improvements  or  critical  materials  required,  or  both,  if  any. 
F.  ACQUISITION  STRATEGY 

1.  The  order  of  magnitude  of  resources  the  DOD  Component  is  willing  to  commit 
to  satisfy  the  need.  This  resource  estimate  is  intended  to  serve  as  a  frame  of 
reference  and  will  not  be  considered  a  threshold. 

2.  Approach  to  concept  exploration,  P3l,  tailoring  of  the  strategy  to  accom 
modate  unique  program  aspects. 

3.  Extent  of  design  competition  contemplated  in  subsequent  phases. 

4.  Timing  of  Milestone  I. 

5.  Approach  to  reduction  of  support  task. 

6.  Strategy  for  constraining  cost  growth  in  production,  maintenance,  and  opera¬ 
tion. 


The  Navy  is  using  the  JMSNS  as  the  principal  re¬ 
quirements  document  for  major  •  acquisition  pro¬ 
grams.  The  JMSNS  is  prepared  by  one  of  the  Mission 
Sponsors,  who  are  Deputy  Chiefs  of  Naval  Opera¬ 
tions  (DCNO)  or  Directors  responsible  for  the 
various  warfare  areas  (e.g.,  DCNO  (Air  Warfare)  or 
Director,  Naval  Intelligence). 

In  the  Air  Force,  requirements  originate  in  the 
operating  commands,  such  as  the  Tactical  Air  Com¬ 
mand,  where  they  are  documented  as  statements  of 
operational  need  (SON).  Those  SON  that  may  lead  to 
major  system  acquisition  programs  are  transformed 
into  JMSNS  by  the  Deputy  Chief  of  Staff  Operations, 
Plans,  and  Readiness)  (AF/XOX)  and  the  Deputy 
Chief  of  Staff  (Research,  Development,  and  Acquisi¬ 
tion)  (AF/RDQ). 

The  procedures  established  for  processing  the 
JMSNS  call  for  the  originating  service  to  submit  the 


MNSNS  to  the  Defense  Acquisition  Executive  (DAE) 
not  later  than  the  POM  submission  in  which  funding 
is  included  for  a  major  system  new  start. 

When  a  Joint  or  OSD/OJCS  JMSNS  is  submitted, 
the  SECDEF  decision  will  be  documented  in  a 
Secretary  of  Defense  Decision  Memorandum 
(SDDM). 

The  SDDM  shall  specify  the  lead  DOD  component 
and  provide  explicit  guidance  on  the  responsibilities 
of  the  participating  DOD  components,  including 
threat  support.  The  lead  DOD  component  will  assign 
the  program  manager  and  request  the  other  par¬ 
ticipating  DOD  components  to  assign  deputy  pro¬ 
gram  managers.  The  lead  DOD  component  will  also 
establish  program  objectives  by  promulgating  a  pro¬ 
gram  charter  after  coordinating  with  the  other  par¬ 
ticipating  DOD  components. 
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Requirements  for  major  tactical  command  and 
control,  and  communications  (C3)  systems  are  pro¬ 
cessed  differently  than  requirements  for  other 
systems.  Because  of  the  interoperability  of  re¬ 
quirements  of  C3  systems  and  their  implications  for 
unified  commands,  the  Joint  Chiefs  of  Staff  are 
specifically  charged  with  validating,  rather  than 
merely  commenting  on,  C3  requirements.2  This 
validation  is  usually  based  on  a  statement  of  re¬ 
quirements  that  is  much  more  detailed  than  a 
JMSNS.  Use  of  the  detailed  statement  of  operational 
requirements,  however,  does  not  preclude  use  of  a 
JMSNS  prior  to  program  initiation.  When  a  JMSNS 
or  Joint-JMSNS  is  used  for  a  'C3  system  acquisition, 
processing  can  be  expected  to  be  the  same  as  for  any 
other  JMSNS  or  Joint-JMSNS. 

The  DOD  has  also  established  special  arrange¬ 
ments  for  processing  armaments  and  munitions  re¬ 
quirements.  An  Armament/Munitions  Requirements 
and  Development  (AMRAD)  Committee  has  been 
established  by  the  Deputy  Secretary  of  Defense.  The 
committee  is  staffed  by  members  of  the  research  and 
development  directorates  of  the  separate  services 
and  reports  to  the  Under  Secretary  of  Defense  for 
Research  and  Engineering.3  Although  the  objectives 
of  most  joint  programs  are  outside  the  purview  of 
AMRAD,  the  committee  has  more  than  ten  years’  ex¬ 
perience  in  reconciling  diverse  requirements  and  has 
established  a  protocol  for  their  harmonization.  A 
program  manager  faced  with  the  task  of  developing 
or  revising  requirements  for  a  joint  program  may  find 
the  committee’s  experience  valuable. 

The  Program  Manager's  Role  in  Establishing 
Requirements 

The  logical,  and  presumably,  intended  sequence  of 
events  in  an  acquisition  is  for  the  JMSNS  or  other  re¬ 
quirements  document  to  be  approved  prior  to  initia¬ 
tion  of  the  program  and  appointment  of  the  program 
manager.  In  practice,  events  may  not  occur  in  that 
order.  Many  are  being  written  to  support  existing 
programs.  Furthermore,  because  many  joint  pro¬ 
grams  are  created  by  merging  two  or  more  single¬ 
service  programs,  or  by  existing  Joint  Program  Of¬ 
fices,  the  joint  program  manager  may  find  himself  in¬ 
volved  in  preparing,  coordinating  or  revising  joint 
JMSNS  or  JOR.  In  any  case,  he  should  ensure  that 
the  statement  of  requirements  meets  the  needs  of  the 
joint  program. 

Several  important  characteristics  of  joint  require¬ 
ments  documents  must  be  kept  in  mind.  They  are 
negotiated  statements.  The  tendency  is  for  each  serv¬ 
ice  to  overstate  or  overspecify  requirements  to  en¬ 
sure  that  its  needs  are  met.  The  working  of  the  re¬ 


quirements  may  be  a  compromise  to  which  each  serv¬ 
ice  may  agree,  but  interpret  differently.  Some  key 
aspects  of  the  requirements  may  be  omitted,  either 
through  oversight  or  because  agreement  was  not  pos¬ 
sible.  Finally,  many  requirements  of  each  of  the  serv¬ 
ices  will  not  be  specified  in  any  requirements  docu¬ 
ment,  but  will  come  to  light  as  the  program  pro¬ 
gresses  and  the  requirements  are  translated  into  en¬ 
gineering  specifications.  For  example,  the  scope  of 
work  defined  in  a  contract  may  incorporate  by  refer¬ 
ence  Military  Standard  Specifications  which  are 
standard  in  one  service,  but  which  either  conflict 
with  or  fail  to  meet  the  needs  of  another  service. 

At  the  outset  of  a  joint  program,  the  joint  program 
manager  should  conduct  a  detailed  technical  require¬ 
ments  review  that  examines  mission  needs,  opera¬ 
tional  concepts  and  environments,  and  performance 
parameters.  He  should  ensure  that  requirements  are 
understood,  that  conflicts  are  resolved,  and  that 
there  is  sufficient  latitude  to  make  the  trade-offs 
essential  to  any  program’s  success.  This  review 
should  accomplish  the  following: 

—identify  the  similarities  and  differences  in  the  serv¬ 
ices’  requirements  and  in  their  operational  environ¬ 
ments 

—force  a  clear  distinction  between  the  “like  to  have” 
and  “must  have”  requirements 
—identify  any  requirement  that  mandates  a  specific 
technical  approach 

—identify  areas  of  technical  risk  or  uncertainty 
—identify  the  similarities  and  differences  in  the  serv¬ 
ices’  logistic  concepts,  requirements,  and  pro¬ 
cedures,  including  their  approach  to  the  implementa¬ 
tion  of  the  life-cycle  cost  concept 

Once  the  requirements  of  each  service  are  well 
understood,  the  joint  program  manager  should  de¬ 
fine  the  set  of  essential  requirements  which  is  most 
demanding  in  terms  of  cost,  schedule,  and  perform¬ 
ance  criteria.  This  will  require  determining  which  re¬ 
quirements  are  subsumed  by  others.  It  will  also  re¬ 
quire  determining  the  extent  to  which  commonality 
of  hardware  and  software,  frequently  an  explicit  or 
implied  goal  of  a  joint  program,  is  a  valid  require¬ 
ment  and  is  achievable.  Some  joint  programs  will  be 
considered  successful  only  if  they  develop  identical 
or  nearly  identical  systems  for  use  in  all  services.  The 
value  of  other  joint  programs,  however,  may  be  only 
in  sharing  the  costs  of  concept  formulation  and  vali¬ 
dation  or  in  coordinating  the  engineering  develop¬ 
ment  of  systems  peculiar  to  each  service  and  en¬ 
suring  their  interoperability;  trying  to  develop  iden¬ 
tical  or  nearly  identical  systems  for  all  the  services 
may  frustrate  the  program  and  lead  to  its  failure. 
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The  preparation  for  each  milestone  review  (see 
Chapter  5,  Program  Review)  should  include  a  re-ex¬ 
amination  of  the  same  items  reviewed  at  the  initia¬ 
tion  of  the  joint  program.  This  re-examination 
should  determine  not  only  that  the  participating  serv¬ 
ices;  perceptions  of  the  requirements  have  not 
changed,  but  also  that  the  threat  or  other  basis  for 
establishing  the  system's  need  remains  consistent 
with  the  initiating  need.  A  revised  threat  assessment 
will  bring  about  a  redirection  of  other  elements  of  the 
JMSNS  (or  OR).  Although  the  program  manager  is 
frequently  advised  to  avoid  change,  he  must  take  the 
opportunity  afforded  by  the  review  process  to  ensure 
that  his  program  is  meeting  the  current  and  pro¬ 
jected  threat  and  that  test  and  evaluation  will 
demonstrate  the  fulfillment  of  current  and  projected 
mission  requirements. 

In  dealing  with  the  contractor,  the  joint  program 
manager  must  ensure  that  the  statements  of  program 
requirements— that  is,  interpretation  of  requirements 
within  the  scope  of  the  contract— emanate  from  one 
source:  his  PCO.  There  must  be  no  other  source,  of¬ 
ficial  or  unofficial,  stated  or  implied.  This  is  the  only 
way  the  joint  program  manager  can  maintain  control 
of  the  program  and  hold  the  contractor  accountable. 

Footnotes 

1.  Shortly  before  the  Joint  Commander  signed  this  guide,  the  Deputy 
Secretary  of  Defense,  Frank  C.  Carlucci  signed  DOD  Directive  5000.1  on 
29  March  1982  Also,  on  12  April  1982,  the  Undersecretary  of  Defense, 
Research  and  Engineering,  Richard  D.  DeLauer,  promulgated  by 
memorandum  major  defense  system  acquisition  program  documentation 
format.  Because  of  the  close  proximity  of  these  events,  the  policy  and  re¬ 
quirements  of  these  documents  may  not  be  fully  included  in  this  guide. 
Accordingly,  the  reader  should  seek  additional  guidance  from  these 
source  documents. 

2.  Department  of  Defense  Directive  4630.5,  “Compatibility  and 
Commonality  of  Equipment  for  Tactical  Command  and  Control,  and 
Communications.” 

3.  The  members  of  the  AMRAD  Committee  are  each  0-6  rank  of¬ 
ficers  on  permanent  assignment  from  the  following  service  headquarters 
organizations:  Army— Deputy  Chief  of  Staff  for  Research,  Development 
and  Acquisition  (DAMA-AMRAD);  Navy— Office  of  Research,  Develop¬ 
ment,  Test  and  Evaluation  (OP  098W);  Marine  Corps— Deputy  Chief  of 
Staff  for  Research,  Development  and  Studies  (MC-RDS);  and  Air 
Force— Deputy  Chief  of  Staff,  Research,  Development,  and  Acquisition 
(AF/RDQRM). 


3-4 


CHAPTER  4 
Acquisition  Strategy 


Acquisition  strategy  is  the  conceptual  basis  for  all 
planning  for  accomplishing  specified  goals  and  ob¬ 
jectives  to  attain  a  mature  and  logistically  support¬ 
able  weapon  system  or  equipment.  It  gives  an  over¬ 
view  of  management  concepts  and  program  manager 
(PM)  actions  planned  to  ensure  satisfaction  of  the  ap¬ 
proved  mission  need.  The  acquisition  strategy  covers 
every  phase  of  the  development  of  a  major  weapon 
system  to  include  operation  and  maintenance  consid¬ 
erations.  At  any  stage  of  the  acquisition  process,  the 
strategy  must  address  the  remaining  life  of  the  pro¬ 
gram.  Many  of  the  details  of  the  strategy,  however, 
need  only  be  planned  for  the  imminent  acquisition 
phase. 

Because  no  two  programs  are  exactly  alike,  each 
requires  a  tailored  acquisition  strategy.  A  joint  pro¬ 
gram  offers  another  dimension  of  the  acquisition 
strategy  for  management  consideration.  A  joint  pro¬ 
gram  strategy  can  be  structured  from  the  beginning  if 
the  proper  multiservice  requirements  fit  can  be 
negotiated.  DOD  Directive  5000.1  requires  that 
“acquisition  of  equipment  satisfying  DOD  compo¬ 
nent  needs  should  also  include  consideration  of  in¬ 
terservice  and  intraservice  standardization  and  inter¬ 
operability  requirements.”  This  consideration  should 
be  made  prior  to  the  issuance  of  a  secretary  of 
defense  decision  memorandum  (SDDM)  specifying  a 
lead  service  and  providing  explicit  guidance  on  the 
responsibilities  of  the  participating  services. 

Chapters  2  and  3  discuss  joint  program  initiation 
and  requirements.  It  is  sufficient  to  summarize  from 
these  chapters  that  when  the  early  stages  of  the  ac¬ 
quisition  process  are  conducted  properly,  the  follow¬ 
ing  goals  should  be  achieved: 

—The  system’s  performance  specifications  match  its 
mission  requirements. 

—Alternate  ways  of  performing  the  mission  are  ex¬ 
plored  before  systems  are  selected. 

—A  variety  of  associated  technologies  and  subsys¬ 
tems  are  considered,  and  the  development  is  initi¬ 
ated  so  that  the  technology  will  be  available  to  meet 
new  threats  and  needs. 

Joint  service  programs  allow  for  development  of 
competing  alternate  technology  approaches  by  the 
participating  services.  The  JMSNS  process  tends  to 
reduce  the  influence  of  service  and  contractor  advo¬ 


cacy  in  deciding  what  systems  are  to  be  acquired  and 
help  ensure  that  alternatives  for  satisfying  the  mis¬ 
sion  need  are  considered. 

Program  Management  Authority 

The  program  manager’s  authority  to  conduct  the 
joint  program  should  be  delineated  in  a  joint  pro¬ 
gram/project  manager  charter  as  required  in 
AFLC/AFSC  R  800-2/AMCR  70-59/NAVMATINST 
5000. 10A.1  Normally,  this  will  be  based  on  a  secre¬ 
tary  of  defense  decision  memorandum.  The  lead 
service  assigns  the  program  manager  and  requests 
the  other  participating  services  to  assign  deputy  pro¬ 
gram  managers.  The  lead  service  also  establishes  the 
program’s  objectives  by  promulgating  the  program 
charter  after  coordination  with  the  participating 
services. 

Developing  the  Acquisition  Strategy 

Acquisition  strategy  defines  the  interrelationship 
between  management,  technical,  business,  resource, 
force  structure,  support,  testing,  and  the  aspects  of 
the  program. 

The  primary  value  of  strategic  planning  is  the  in¬ 
teractive  process  through  which  the  final  product  is 
developed.  The  acquisition  strategy  evolves  through 
repetition  as  a  dynamic  management  tool  which  must 
be  kept  current  throughout  the  life  of  the  program.  It 
must  also  address  typical  management  issues  from 
development  to  production  that  assess  the  impact  of 
different  levels  of  funding,  problems  in  testing, 
changes  in  requirements,  control  of  engineering 
changes,  length  of  product  maturation,  and  effects  of 
lead  times.  The  acquisition  strategy  should  delineate 
realistic  responses  to  program  variances  considered 
disruptive  to  key  program  efforts. 

The  acquisition  strategy  should  reflect  the  full 
scope  of  the  program  with  sensitivity  to  the  acquisi¬ 
tion  process,  imagination,  and  practical  judgment  of 
program  managers.  Whenever  large  procurement 
quantities  and  relatively  high  unit  costs  are  part  of 
the  acquisition,  the  program  manager  has  a  full 
range  of  acquisition  strategies  available  to  structure 
his  program.  He  should  also  consider  the  use  of  com¬ 
petition  to  obtain  the  trade-offs  between  cost,  per¬ 
formance,  and  schedule  supportability  to  the  best  ad- 
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Figure  4-1 

OUTLINE  OF  NAVMATI NST  5000.29  ON  SYSTEM  ACQUISITION 
STRATEGY  PLANNING 


I.  OBJECTIVES  AND  CONSTRAINTS 

A  .  Statement  of  need — synopsis  of  JMSNS 

B  .  Summary  of  technical  development— advances  in  technology  required 
C  .  Relationship  to  other  programs 

D  .  Program  objectives— quantifiable  objectives  as  parameters  and  non-quantifiable  objectives  as  qualita¬ 
tive  judgments 

E  .  Assumptions — interrelated  events  with  probabilities  associated  with  their  occurrence 
F  .  Constraints — variable  and  non-variable  constraints,  resources  required  vs.  planned  resources  available 
G  .  Major  threat/risk  factors 

II.  STRATEGY  TO  ACHIEVE  OBJECTIVES 

A  .  Dealing  with  constraints 
B  .  Anticipation  of  changes  in  major  threat/risks 
C  .  Development  of  alternatives 

D  .  Selection  among  alternatives  and  the  timing  of  key  selection  decisions — maintenance  of  competition, 
expansion  of  the  industrial  base,  integrated  logistics  support  (ILS),  and  affordability 
E  .  Utilization  of  organizational  assets — industry,  in-house  labs,  universities,  etc. 

F  .  Planning  and  control  of  critical  program  activities— commitment  and  contingency  planning,  respon¬ 
siveness  to  changes 

III.  IMPLEMENTATION 

A  .  Developing  and  scheduling  of  interactive  plans 

1.  Funding,  budgeting,  and  business 

2.  Contracting 

3.  Test  and  evaluation 

4.  Integrated  logistics  support 

5.  Configuration  and  technical  management 

6.  Work  breakdown  structure 

7.  Software 

8.  R&M 

9.  Personnel,  training,  and  force  development 

10.  Technical  developments  and  assessment 


vantage  of  his  program  where  there  is  a  net  benefit  to 
the  government. 

The  acquisition  strategy  should  not  contain  plan¬ 
ning  details;  it  is  intended  to  serve  as  an  overall 
strategy  for  functional  implementation  plans.  The  ac¬ 
quisition  strategy  for  the  airborne  self  protection 
jammer  (ASPJ)  is  approximately  20  pages  long.  For¬ 
mulated  by  the  PM  with  the  assistance  and  advice  of 
acquisition,  contracts,  and  other  functional  special¬ 
ists,  the  acquisition  strategy  is  coordinated  with  the 
appropriate  materiel  develoment  commands 
(DARCOM,  AFSC,  AFLC,  NAVMAT).  Concurrence 
at  the  materiel  development  commands  assures  de¬ 
velopment  and  establishment  of  a  consensus  and  ad¬ 
vocacy  for  the  acquisition  strategy  early  in  the  acqui¬ 
sition  process.  Figure  4-1  illustrates  the  suggested 
topics  which  might  be  included  in  the  acquisition 
strategy. 

The  acquisition  strategy  should  be  developed  im¬ 
mediately  following  Program  Initiation  and  the  ap¬ 
pointment  of  a  program  manager.  It  will  become  a 
source  plan  for  the  System  Concept  Paper  (SCP)  at 


Milestone  1.  It  will  address  how  program  alternatives 
are  to  be  developed  and  evaluated,  and  how  selection 
of  the  most  promising  altemative(s)  will  be  made. 
The  acquisition  strategy  must  be  tailored  to  the 
unique  requirements  of  a  specific  acquisition  effort 
and  the  different  phases  of  the  acquisition  cycle.  It  is 
not  a  formal  document  and  does  not  require  formal 
higher-level  approval  (except  for  the  Navy,  where 
CNM  approval  is  required).  However,  the  program 
manager  is  required  to  keep  all  management  levels 
informed  of  his  acquisition  strategy  and  to  sum¬ 
marize  specific  areas  at  milestone  decision  points  as 
part  of  the  DCP/IPS.  Prior  to  Milestone  II,  the  pro¬ 
gram  manager  should  complete  his  acquisition 
strategy  for  full-scale  development  and  production. 
The  strategy  for  production  must  be  updated  prior  to 
Milestone  III. 

Technical  Advances 

The  acquisition  strategy  should  include  a  listing  of 
critical  pacing  technology  advances  required  to 
satisfy  the  program  thresholds.  The  initial  acquisi- 


4-2 


Figure  4-2 

METHODS  TO  MAINTAIN  COMPETITION 
DURING  THE  LIFE  CYCLE 


tion  strategy  after  Program  Initiation  may  only  con¬ 
tain  a  few  pacing  technology  advances  required  since 
alternatives  have  not  yet  been  explored.  As  the  con¬ 
cept  formulation  phase  proceeds,  however,  advances 
should  become  defined  in  detail  as  the  preferred  al¬ 
ternatives  are  considered.  The  critical  pacing  tech¬ 
nology  advances  required  for  each  alternative  drives 
the  technology  risk  assessment  in  the  analysis  of  the 
alternative  concepts.  Once  the  preferred 
altemative(s)  is  chosen  at  Milestone  I,  the  advances 
required  should  be  well  known  and  an  evaluation  of 
risks  for  developing  those  technologies  to  the  point 
of  being  able  to  meet  the  performance,  cost,  sched¬ 
ule,  and  supportability  thresholds  should  be  under¬ 
stood.  The  program  manager  must  then  manage 
these  risks  through  the  acquisition  strategy  by  as¬ 
signing  and  controlling  critical  resources  (time, 
money,  personnel)  to  achieve  the  required  technol¬ 


ogy  advances  with  special  attention  to  the  critical 
pacing  technologies. 

When  technical  risk  and  progress  are  acceptable, 
parallel,  short-term  fixed-price  contracts  are  some¬ 
times  used  to  evaluate  and  explore  selected  con¬ 
cepts.  This  can  aid  in  reducing  technical  uncertain¬ 
ties  for  alternative  approaches.  Unsuccessful  ap¬ 
proaches  are  eliminated  by  continuous  evaluation  of 
contractor  and  in-house  laboratory  efforts.  Figure 
4-2  illustrates  parallel  development  efforts  to  main¬ 
tain  competition.  Two  government  laboratories, 
three  industry  participants,  and  one  European  con¬ 
tractor  develop  and  investigate  feasibility  of  various 
concepts.  The  successful  concept  feasibility  study 
from  one  government  laboratory  is  transferred  for 
the  demonstration  and  validation  phase.  A  fly-off  be¬ 
tween  the  three  participants’  prototypes  results  in 
selection  of  one  full-scale  engineering  development 
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approach,  with  a  teaming  arrangement  concluded 
between  the  European  industrial  partner  and  the  re¬ 
maining  U.S.  industry  participant,  resulting  in  a  dual¬ 
production  agreement 

Value  engineering  can  be  a  useful  tool  for  pro¬ 
moting  cost  reduction  in  the  design  and  production 
phases  that  include  government  and  contractor  engi¬ 
neering  efforts.  Besides  a  vigorous  in-house  pro¬ 
gram,  an  incentive  clause  is  included  in  the  contract 
by  which  any  cost  savings  accrued  by  a  contractor  be¬ 
cause  of  his  value  engineering  program  is  shared 
with  the  contractor.  Value  engineering  uses  various 
analytic  techniques  to  eliminate  or  reduce  the  cost  of 
a  component  in  the  system  not  necessary  to  maintain 
required  performance,  quality,  maintainability,  relia¬ 
bility,  standardization,  or  interchangeability. 

Logistics  planning  and  programming  strategy  will 
be  directed  towards  avoiding  significant  supportabil- 
ity  and  readiness  problems.  The  anticipated  prob¬ 
lems  are  to  be  identified  as  critical  technology  ad¬ 
vances  when  they  are  sufficiently  significant  as  to  af¬ 
fect  performance  thresholds  for  the  system.  In  addi¬ 
tion,  industry  capacity  to  produce  critical  compo¬ 
nents,  long  subcontractor  leadtimes,  use  of  commer¬ 
cial  systems  and  components,  and  use  of  commercial 
logistics  support  should  be  considered.  Centralizing 
the  defense  logistics  functions  via  single-service  man¬ 
agers  (such  as  the  Army  as  the  single  manager  for 
DOD  conventional  ammunition  production  and  in¬ 
ventory),  consolidating  management  of  individual 
non-consumable  stock-numbered  items  of  joint- 
service  equipment  by  the  Defense  Retail  Interservice 
Support  Program,  and  expeditiously  transferring 
consumable  items  to  the  Defense  Logistics  Agency 
and  use  of  the  standard  integrated  support  manage¬ 
ment  system  (SISMS)  should  be  considered  for  very 
early  implementation  in  the  initiation  of  the  logistics 
program.  By  coupling  the  manpower  and  logistics 
functions,  support  of  the  weapons  system  has  been 
emphasized  in  the  acquisition  process.  Recent 
DSARC  decisions  have  placed  a  major  emphasis  on 
reliability  and  maintainability  and  their  relationship 
to  manpower  and  logistics.2 

The  chapters  on  Logistics  and  Engineering  Man¬ 
agement  discuss  the  various  aspects  of  technical 
management  to  include  core  DOD  requirements, 
configuration  management,  pre-planned  produce  im¬ 
provement,  software  management,  and  the  joint  en¬ 
gineering  review  process. 

Contract  Strategies 

The  program  may  frequently  be  constrained  by 
such  factors  as  proprietary  data,  unique  contractual 
terms,  or  other  commitments  made  prior  to  the  cur¬ 
rent  acquisition  strategy  cycle.  For  example,  technol¬ 


ogy  developed  by  a  contractor  at  his  own  expense 
under  independent  research  and  development  pro¬ 
gram  may  be  available  to  the  government  only  if  the 
contractor’s  participation  in  the  program  continues. 
The  program  manager  should  identify  all  such  con¬ 
tracts  or  commitments  and  understand  their  influ¬ 
ence  on  his  program.  Many  programs  depend  upon 
other  projects  and  government  agencies  for  compo¬ 
nents  to  other  projects.  An  example  is  the  multiple 
launch  rocket  system  (MLRS).  The  derivative  vehicle 
used  as  the  basis  carrier  is  the  responsibility  of  the 
Infantry  Fighting  Vehicles  Systems  Office.  The  pro¬ 
ject  manager’s  office  for  Selected  Ammunition  at 
Picatinny  Arsenal  is  responsible  for  modifying  and 
supplying  the  M-42  submissions.  Harry  Diamond 
Laboratories  is  developing  the  SM-445  electronic 
fuse  for  the  MLRS. 

The  program  manager,  via  his  contracting  officer, 
has  access  to  contract  types  that  have  evolved  and 
survived  the  test  of  time.  They  have  been  designed  to 
fit  particular  circumstances  and,  when  appropriate, 
create  a  fair  and  equitable  legal  relationship  for  par¬ 
ticipants.  Each  major  system  acquisition  program 
has  unique  features;  differences  in  the  contracting 
approach  to  harmonize  time,  cost,  technology,  and 
management  environment  can  be  expected.  The  ac¬ 
quisition  strategy  allows  innovative  contracting  ap¬ 
proaches.  Through  consideration  of  program  goals 
and  objectives,  the  PM  should  be  able  to  examine 
and  schedule  contract  decisions,  refine  contracting 
strategy  to  maintain  competition  when  practical, 
utilize  resources  most  effectively,  and  minimize  de¬ 
velopment  time  by  allowing  contractors  and  in-house 
personnel  to  explore  competing  methods.  Con¬ 
tracting  is  a  tool  in  the  acquisition  process,  not  a  sub¬ 
stitute  for  management.  The  acquisition  strategy 
must  accommodate  procurement  lead  times,  pre¬ 
clude  “technical  leveling”  between  competing  con¬ 
tractors,  and  provide  innovation  in  proposal  submit¬ 
tals  for  the  next  planned  increment. 

In  order  to  refine  the  acquisition  strategy,  the  Air 
Force  finds  it  useful  to  convene  a  Business  Strategy 
Panel  (BSP),  as  outlined  in  AFSC  Regulation  70-2, 
to  have  a  corporate  review  of  the  overall  strategy 
prior  to  its  final  formulation  by  the  PM.  The  BSP  dis¬ 
cusses  the  overall  acquisition  strategy  including  guid¬ 
ance/requirements,  schedule,  funding,  type  of  con¬ 
tract,  special  clauses,  incentives,  manufacturing, 
logistic,  and  product  assurance  aspects.  The  panel 
operates  as  an  advisory  body  only.  The  purpose  is  to 
make  the  PM  aware  of  the  contracting  and  manufac¬ 
turing  lessons  learned  from  acquisition  experience 
and  also  suggest  strategies  that  will  best  satisfy  the 
program  requirements  and  objectives. 

After  the  acquisition  strategy  has  been  finalized 
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and  the  solicitation  is  being  prepared,  a  Draft  Re¬ 
quest  for  Proposal  (DRFP)  may  be  used  to  solicit 
feedback  from  industry  on  the  proposed  acquisition. 
Offerors  should  be  encouraged  to  challenge  require¬ 
ments  that  are  considered  significant  cost  drivers  and 
to  suggest  revisions  to  performance,  schedules,  or 
other  contractual  requirements  which  could  enhance 
the  program.  The  industry  feedback  can  provide 
significant  cost  savings  and  program  improvements 
by  deleting  unnecessary  requirements  and  overly 
complex  elements. 

Just  as  prototyping  is  designed  to  increase  compe¬ 
tition  during  the  research  and  development  phases  of 
the  systems  acquisition  process,  several  methods  are 
used  to  increase  competition  during  production. 
Breakouts  involve  competitive  reprocurement  of 
spare  parts  and  components  for  weapon  systems. 
Breakout  has  been  especially  cost  effective  when  the 
weapon  system  producer  is  an  assembler  and  piece 
parts  are  available  from  other  vendors. 

Under  second  sourcing,  firm(s)  performing 
development  provide  the  government  a  complete 
technical  data  package  (TDP).  The  DOD,  after 
validating  the  drawings,  specifications,  and  other 
technical  information,  transfers  the  package  to  other 
suppliers  to  establish  production  lines.  Several  pro¬ 
duction  lines  can  be  maintained  throughout  the  pro¬ 
duction  phase.  Duplication  of  tooling  and  other  set¬ 
up  costs  normally  require  production  runs  sufficient¬ 
ly  large  to  absorb  these  costs.  Second  sourcing  or 
threat  of  second  sourcing  can  be  effective  in  reducing 
costs  through  competitive .  forces.  It  has  been  used 
successfully  for  small  missiles  (Sidewinder,  Sparrow, 
and  Bullpup),  target  drones,  aircraft  engines,  and 
torpedoes. 

Leader-follower  procurement  establishes  contrac¬ 
tual  arrangements  during  the  development  phase  for 
the  contractor  to  transfer  technology  to  other  firms 
for  establishment  of  production  lines.  This  strategy 
has  been  used  extensively  in  naval  shipbuilding  pro¬ 
grams,  the  TOW  missile  system,  and  for  transitioning 
production  capabilities  to  our  European  NATO 
allies.  The  leader-follower  concept  has  been  used 
more  for  increased  production  capacity  than  in¬ 
creased  competition,  partly  because  of  the  difficulty 
in  motivating  contractors  to  transfer  technical  exper¬ 
tise  with  the  threat  of  losing  future  contracts. 

Codevelopment  is  an  effective  technology  transfer 
policy  to  support  cooperative  development  within 
NATO.  Teaming  of  contractors  provides  benefits  of 
price  and  technical  competition.  Teaming  is  especial¬ 
ly  useful  when  one  contractor  does  not  have  all  the 
resources  to  accomplish  development  and  produc¬ 
tion. 


Competition  occurs  during  development  and  for 
initial  and  subsequent  production  contracts.  Hence, 
a  technology  clause  in  the  contract  requires  the 
transfer  of  data  and  technical  information  to  the  con¬ 
tractor  winning  the  production  competition  should  it 
not  be  the  developer  of  the  technology.  The  new  firm 
pays  royalties  and  compensation  for  technical  assist¬ 
ance  to  the  licensor.  There  are  problems  with  this 
strategy  because  many  companies  are  reluctant  to 
part  with  proprietary  information.  This  can  result  in 
critical  production  delays  and  in  “buy-ins”  by  firms 
desiring  trade  secrets. 

These  strategies  require  the  program  manager  to 
possess  an  adequate  data  base,  a  knowledgeable  in- 
house  team,  and  a  detailed  definition  of  the  objec-- 
tives  of  the  contracting  strategy.  Unlimited  patent 
and  data  rights  must  belong  to  the  government  for 
competition  to  be  effective.  Specific  clauses  for  tech¬ 
nology  transfer  must  be  inserted  in  the  initial  request 
for  proposals  and  contract(s)  to  assure  that  pro¬ 
prietary  rights  are  not  a  roadblock  to  competition. 
The  contractor  should  at  least  be  required  to  list  all 
proprietary  rights  prior  to  the  contract  initiation.  It  is 
well  recognized  that  a  technical  data  package  (TDP) 
is  rarely  adequate  for  recompetition;  some  form  of 
technology  transfer  is  normally  required  between 
contractors.  Objectives  in  contracting  strategy  may 
be  achieving  lowest  cost,  enhancing  performance, 
compressing  the  development  schedule,  enhancing 
competition,  or  a  host  of  other  quantitative  and 
qualitative  factors. 

Multiyear  contracting  is  a  method  of  planned  ac¬ 
quisition  for  periods  of  up  to  5  years  without  having 
total  funds  available  at  award  time.  Program  year 
quantities  are  financed  initially  with  remaining  quan¬ 
tities  budgeted  for  in  the  Five  Year  Defense  Plan. 
Contractors  are  protected  against  loss  from  a  con¬ 
tract  cancellation,  for  up  to  $5  million  on  non¬ 
recurring  costs,  in  case  budgeted  funds  for  future 
years’  requirements  are  not  appropriated.  Multiyear 
contracting  encourages  competition  by  broadening 
the  competitive  base  by  participation  of  firms  not 
otherwise  willing  to  compete  for  lesser  quantities, 
reduces  costs  by  allowing  a  greater  quantity  base  for 
facilitization  for  production  and  stabilization  of  the 
work  force,  and  enhances  standardization. 

In  considering  the  above  techniques  to  enhance 
competition  in  development  and  production  phases, 
an  economic  analysis  is  required  to  estimate  net 
long-term  savings  and  impact  of  technical  competi¬ 
tion.  Non-recurring  and  start-up  costs,  learning- 
curve  effect,  technology  transfer  cost,  inflation  ef¬ 
fects,  and  hardware  costs  must  be  considered.  The 
government  administrative  personnel  burden  and 
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costs  for  additional  engineering,  contracting,  and 
testing  support  should  also  be  considered. 

Using  competition  to  drive  research  and  develop¬ 
ment  may  result  in  shortening  the  acquisition  cycle 
by  allowing  “concurrency,”  substitution  of  a  shorter 
maturation  phase  with  parallel  completion  of 
research  and  development.  This  meets  the  challenge 
to  shorten  the  acquisition  cycle  time  to  field  a 
system.  Concurrency  can  be  most  effectively  used  on 
low-technology  systems  where  high  schedule  and 
costs  risk  are  acceptable  due  to  urgency  of  the  re¬ 
quirement  to  meet  critical  threats  or  needed  capabil¬ 
ities.  Examples  of  current  systems  employing  a  con¬ 
currency  acquisition  strategy  are  the  Multiple 
Launch  Rocket  System  (MLRS),  Division  Air  De¬ 
fense  (DIVAD)  Gun,  Single  Channel  Ground  and  Air¬ 
borne  Radio  Subsystems,  Air  Launched  Cruise  Mis¬ 
sile  (ALCM),  and  M-l  tank.  Without  concurrency  on 
these  systems,  the  initial  operating  capability  (IOC) 
would  be  delayed  2-4  years. 

Financial/Business  Strategy 

Once  an  acquisition  strategy  is  accepted,  the  PM 
must  budget  funds  to  accomplish  necessary  tasks  and 
structure  the  PM  office  to  meet  requirements  in  con¬ 
tracting,  techical  management,  integrated  logistics 
support,  business  management,  etc.  The  PM  must 
begin  to  manage  the  technical,  cost  and  schedule 
risks,  accommodating  the  funding  and  policy  con¬ 
straints,  selecting  and  developing  strategy  alterna¬ 
tives,  maintaining  competition  where  practical,  and 
controlling  critical  program  events  and  activities. 
The  acquisition  strategy  must  also  address  utilization 
of  available  assets,  to  include  support  via  matrix 
management,  systems  contractors,  government  labo¬ 
ratories,  universities,  and  industry. 

One  method  sometimes  employed  by  program  of¬ 
fices  to  reduce  the  number  and  frequency  of  contract 
actions  they  manage  is  to  use  an  integrating  contrac¬ 
tor  concept.  This  means  a  major  •  contractor  is 
selected  essentially  to  coordinate  activities  of  a  family 
of  other  contractors  working  on  various  parts  of  the 
program. 

DOD  Directive  5000.1  directs  that  cost  parameters 
be  translated  into  design  requirements.  DOD  Direc¬ 
tive  5000.28,  explains  “design-to-life-cycle-cost”  as 
an  integral  part  of  the  program  management,  not  a 
nonrecurring  consideration. 

Another  OMB  Circular,  A-76,  is  the  basic  guide  for 
use  of  in-house  versus  contractor  support.  It  specifies 
that  procurement  from  industry  is  the  preferred 
method  to  satisfy  the  government’s  needs  for  pro¬ 
ducts  and  services.  The  complexities  of  this  policy 
are  important  when  programs  reach  test  and  evalua¬ 
tion  (i.e.,  who  should  do  it,  contractors  or  govern¬ 


ment  agencies?)  and  deployment  (i.e.,  should  the 
services  rely  on  contractor  support?).  The  guidelines 
within  DOD  are  not  clear,  and  sometimes  vary  from 
service  to  service. 

Affordability  is  another  issue  to  be  addressed  by 
the  program  manager  and  the  service.  The  Justifica¬ 
tion  of  Major  Systems  New  Starts  (JMSNS)  must  in¬ 
clude  an  analysis  of  overall  capability  requirements, 
priority  of  need,  and  resources  required.  The  acquisi¬ 
tion  strategy  should  address  R&D,  production  and 
life-cycle  cost  goals,  and  thresholds  as  developed 
during  the  acquisition  process.  Adequate  service 
need  and  priority  is  indicated  by  full  funding  of  the 
program.  At  DSARC  I,  the  program  objectives  me¬ 
morandum  (POM)  and  five-year  development  plan 
(FYDP)  should  indicate  full  funding  of  the  R&D 
phases.  Remaining  R&D  and  production  should  be 
fully  funded  by  DSARC  II.  The  POM  and  FYDP 
should  incude  full  funding  for  production  and  opera¬ 
tions  and  support  (O&S)  by  Milestone  III. 

Besides  the  DSARC  issue  of  affordability,  a  linkage 
has  been  strengthened  between  the  planning,  pro¬ 
gramming,  and  budgeting  system  (PPBS)  and  the  ac¬ 
quisition  review  process  via  the  Defense  Research 
Board  (DRB).  Established  in  April  1978,  the  DRB  is 
chaired  by  the  Deputy  Secretary  of  Defense  and  has 
been  expanded  to  17  regular  members,  including  all 
the  members  of  the  DSARC.  Its  charter  include: 
—Reviewing  proposed  planning  guidance, 
—Managing  the  program  and  budget  review  process, 
—Advising  the  Secretary  of  Defense  on  policy,  plan¬ 
ning,  program  and  budget  issues  and  proposed  deci¬ 
sions, 

—Evaluating  and  reviewing  high  priority  programs 
on  a  regular  basis,  and 

—Assuring  that  major  acquisition  systems  are  more 
clearly  aligned  to  the  PPBS. 

Strategy  for  Reducing  Risk 

At  Milestones  I,  II,  and  prior  to  the  production 
decision,  Milestone  III,  all  program  efforts  should  be 
directed  to  reducing  risk  to  an  acceptable  level. 
Since  that  is  the  fundamental  purpose  of  research, 
development,  test,  and  evaluation,  much  of  the  ac¬ 
quisition  strategy  will  depend  on  what  the  program 
manager  determines  to  be  the  major  remaining  un¬ 
certainties  about  cost,  schedule,  performance,  and 
supportability.  These  uncertainties  will  change,  as 
the  program  progresses,  forcing  reassessment  and 
revision  of  the  acquisition  strategy.  The  acquisition 
strategy  should  specify  those  major  problem  or  risk 
areas  to  be  overcome  to  achieve  the  program  objec-- 
fives  and  goals  and  effect  the  selection  of  the  most 
appropriate  approach. 
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When  program  risks  have  been  identified,  the  pro¬ 
gram  manager  should  identify  the  four  complemen¬ 
tary  methods  available  for  reducing  them  to  an  ac¬ 
ceptable  level: 

—ideas  or  concepts 
—studies  and  analyses 
—prototypes  or  demonstrations 
—tests  and  evaluations 

His  blending  of  the  four  should  be  governed  by  the 
stage  of  the  acquisition  program,  nature  of  risk,  and 
the  time  and  money  available. 

Competitive  demonstrations  are  effective  for  evalu¬ 
ating  alternative  system  designs.  They  must  include 
reaffirmation  that  the  alternative  is  meeting  mission 
need  and  program  objectives,  and  verify  that  the 
chosen  concepts  are  sound  and  perform  in  the  inten¬ 
ded  operational  environment.  Competitive  demon¬ 
strations  can  provide  an  effective  basis  for  selection 
of  the  systems  or  critical  subsystems  to  be  continued 
through  full-scale  engineering  development. 

The  primary  objective  of  the  test  and  evaluation 
program  as  discussed  more  fully  in  the  test  and  eval¬ 
uation  chapter  is  to  discover  significant  technical  and 
operating  deficiencies  to  support  the  acquisition  of 
reliable,  effective,  and  supportable  weapon  systems 
for  our  operating  forces.  The  development  of  a  com¬ 
prehensive  test  and  evaluation  master  plan  as  an  in¬ 
tegral  part  of  the  acquisition  strategy  is  essential. 
Data  from  joint  test  and  evaluation  (JT&E)  programs, 
used  to  evaluate  the  system  suitability  for  the  in¬ 
tended  mission,  for  force  structure  planning,  for 
definition  of  needs,  and  for  weapons  improvement,  is 
to  be  included,  if  appropriate.  In  addition,  foreign 
weapons  evaluation  programs  for  candidate  NATO 
and  ABCA  (American,  British,  Canadian,  Australian) 
alternatives  should  be  ascertained  if  systems  being 
developed,  or  already  developed,  meet  the  require¬ 
ment. 

An  Example  of  an  Acquisition  Strategy— The 
Airborne  Self  Protection  Jammer  (ASPJ) 

The  first  approved  acquisition  strategy  is  the  Air¬ 
borne  Self  Protection  Jammer,  managed  by  the  Ad¬ 
vanced  Tactical  Aircraft  Protection  System  Office, 
PMA-272.  The  Airborne  Self  Protection  Jammer 
(ASPJ)  is  an  on-board  aircraft  defensive  electronics 
countermeasure  (ECM)  system  used  in  conjunction 
with  a  warning  receiver  (LR-67  for  USN  and  ALR-69 
for  USAF)  and  expendable  dispenser  (ALE-39  for 
USN  and  ALE-40  for  USAF),  to  provide  an  advanced 
ECM  suite  for  the  F-14,  F-16,  F-18,  EA-6B,  and 
A6E.  Because  the  ASPJ  has  to  fit  on  these  various 
aircraft,  the  ASPJ  basic  system  is  configured  differ¬ 
ently  by  using  standard  modules  for  the  high-  and 


low-band  receivers  (two  separate  modules),  the  pro¬ 
cessor,  and  the  high-  and  low-band  transmitter  (two 
modules).  The  USAF  Comprehensive  Power  Man¬ 
agement  System,  which  must  interface  with  the  ASPJ 
transmitter  modules  and  the  ALQ-131,  is  90  percent 
common  with  the  ASPJ  receivers  and  processor. 
Specific  OSD  guidance  was  provided  that  all  new 
ECM  developments  must  be  common  for  the  USAF 
F-16,  USN  F-18,  and  other  tactical  aircraft  in  order 
to  reduce  the  total  cost  of  ECM  programs  by 
eliminating  duplicative  development  costs,  obtaining 
production  economies  of  scale,  and  reducing  opera¬ 
ting  and  support  costs.  In  addition  to  the  aircraft 
listed  above,  the  F-lll,  Army  special  mission  air¬ 
craft,  and  NATO  aircraft  are  candidate  aircraft. 
Thus,  PMA-272  is  a  joint  Navy-Air  Force  project- with 
Army  and  NATO  RSI  implications.  Minimum  project- 
cost  is  derived  from  interservice  commonality. 

The  ASPJ  acquisition  strategy  follows  the  basic 
outline  of  the  Naval  Material  Command  Instruction 
5000.29  on  system  acquisition  strategy  planning, 
Figure  4-1.  The  electronic  warfare  mission  area,  mis¬ 
sion  element  need  task,  project-  objectives  and  gui¬ 
dance  from  higher  authority  are  summarized  in  sec¬ 
tion  I  of  the  ASPJ  acquisition  strategy.  The  advances 
in  technology  required  for  the  ASPJ  to  meet  antici¬ 
pated  performance  requirements  are  listed  as  travel¬ 
ing  wave  tubes,  power  supplies,  microwave  inte¬ 
grated  circuits,  microprocessors,  pulse  train 
trackers,  and  digitally  tuned  oscillators.  Planning  as¬ 
sumptions  include  the  satisfaction  of  a  multitude  of 
user  requirements  for  aircraft  listed  previously,  com¬ 
monality  of  equipment,  interservice  sharing  of  R&D 
funding  shortfalls,  required  flexibility  in  the  R&D 
and  production  phases  to  accommodate  changing  re¬ 
quirements  and  additional  aircraft  users,  and  a  for¬ 
mal  DSARC  “new  start’’  to  consolidate  the  various 
joint  user  requirements.  The  relationship  of  ASPJ  to 
candidate  airframes  and  Pod  programs  is  depicted  by 
a  probable  ASPJ  schedule  compared  with  schedules 
of  the  candidate  aircraft.  The  major  risks  and  prob¬ 
lems  are  achieving  a  common  Navy-Air  Force  project- 
completing  the  DSARC  review,  resolving  R&D  short¬ 
falls,  and  integrating  a  common  equipment  with  a 
variety  of  airframe  users.  The  constraints  for  the 
ASPJ  are  that  it  must  fit  into  the  existing  space  in  the 
candidate  aircraft  for  ECM  equipment;  must  function 
with  existing  USN  and  USAF  warning  receivers,  the 
ALR-67  and  ALR-69;  and  the  unit  cost  of  the  system 
must  be  less  than  $400,000  to  meet  affordability 
criteria. 

Section  II  of  the  plan  details  the  strategy  to  achieve 
the  stated  objectives.  Included  in  this  section  is  the 
history  of  similar  procurements,  description  of  prob- 
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lems  of  proliferation  of  ECM  equipment,  appearance 
of  an  ECM  industry,  and  recent  congressional  and 
OSD  guidance  on  interservice  commonality.  Besides 
commonality,  other  acquisition  objectives  are  that 
the  ASPJ  must:  (1)  be  adaptive  with  sufficient  growth 
potential  to  threat  changes,  (2)  be  affordable,  (3) 
maintain  cost  control  and  cost  goals,  and  (4)  maxi¬ 
mize  operational  availability.  The  industrial  base  as¬ 
sessment  determined  that  10  to  13  companies  are  in 
the  competitive  field.  An  assessment  of  the  total 
number  of  anticipated  jammers  required  for  the  USN 
aircraft,  Army  special  mission  aircraft,  F-16,  F-lll, 
FB-111,  and  NATO  is  projected.  The  following  rela¬ 
tionships  were  defined  to  assess  acquisition  alter¬ 
natives: 

—cost/schedule/program  risk 

—production  quantity/unit  costs/average  production 

cost/total  production  costs 

—value  and  history  of  competition  in  ECM  pro¬ 
curements 

Several  R&D  program  options  are  developed  for 
the  ASPJ  with  relative  cost  and  risk  for  comparative 
analysis.  The  urgency  of  the  requirement  for  the 
ASPJ,  the  reduction  in  retrofit  costs  for  the  F-18  if 
the  ASPJ  were  available  earlier,  affordability,  and 
risk  are  dominant  factors  in  the  development  of  the 
ASPJ  acquisition  strategy.  To  obtain  sustained  com¬ 
petition,  teaming  of  companies,  each  capable  of 
building  the  entire  production  end  item,  was  con¬ 
ceived  for  the  R&D  phase.  The  winning  R&D  team 
would  split  and  compete  against  one  another  for 
shares  of  production.  The  development  program  has 
a  two-team  design  competition  followed  by  a  single¬ 
team  fabrication  and  test  phase.  A  moderate  risk  pro¬ 
gram  structure  was  selected.  Risk  is  to  be  controlled 
by  having  two  teams  (four  contractors)  compete  in 
the  design.  Technical  risk  is  to  be  reduced  by  proto¬ 
typing  or  demonstration  only  on  items  that  constitute 
significant  design  or  packaging  risk.  Cost  analysts 
are  to  predict  the  probable  production  cost  of  the 
system.  Figure  4-2  illustrates  the  ASPJ  competitive 
teaming  scheme.  Although  competition  is  to  be  used 
as  the  best  control,  a  series  of  incentives  and  con¬ 
trols  is  also  to  be  used.  The  design  phase  contract  is 
to  be  cost  plus  fixed  fee  (CPFF)  with  contractual  con¬ 
trols  imposed  by  cost  sharing  on  overruns  and  pro¬ 
gress  reported  by  Cost  Performance  Report  (CPR) 
reports.  The  fabrication  phase  contract  is  to  be  cost 
plus  award  fee  (CPAF),  with  Cost/Schedule/Control 
Systems  Criteria  (CSCSC)  used  to  measure  contrac¬ 
tor  performance.  An  equitable  first-production  split 
will  allow  equal  start-up  efforts  and  provide  a  suffi¬ 
cient  production  quantity  and  rate  to  verily  the 
design-to-cost  goal.  An  unequal  share  split  is  an¬ 
ticipated  after  the  first  production  contract  to  main¬ 


tain  competition  controls.  When  the  remaining  pro¬ 
duction  is  reducted  to  a  small  quantity,  a  “winner 
take  all”  bid  will  close  out  production.  Spares  are 
competed  separately.  A  cash  incentive  is  planned  for 
obtaining  the  design-to-cost  goal 

Section  III,  implementation  of  the  strategy,  lists 
the  following  critical  events:  the  acquisition  strategy 
must  pass  OSD  and  OFPP  reviews  for  compliance 
with  OMB  Circular  A- 109,  the  industrial  members 
must  voluntarily  team,  and  the  USAF  and  USN  must 
conclude  a  joint  service  agreement  so  total  produc¬ 
tion  quantities  are  sufficient  to  support  dual  produc¬ 
tion  sources.  The  DSARC  is  to  be  used  as  the  vehicle 
to  gain  agreement  on  the  acquisition  strategy  and 
USAF  commitment  to  the  joint  program.  The  impact 
of  various  possible  funding  cuts  is  assessed  during 
the  design  phase,  fabrication  and  testing  phase,  and 
production  on  the  acquisition  strategy  in  terms  of 
lost  competition,  increased  program  risk,  and  sched¬ 
ule  delay.  The  acquisition  strategy  is  to  be  updated 
before  each  major  milestone,  as  a  result  of  DSARC 
decisions  or  change  in  direction  from  higher 
authorities,  of  if  serious  contractor  problems  surface. 

Conclusions  and  Recommendations 

In  the  day-to-day  press  of  carrying  out  his  acquisi¬ 
tion  plan,  the  program  manager  should  reserve  for 
himself  the  occasional  opportunity  to  reassess  his 
strategy.  He  will  want  to  verily  that  assumptions  con¬ 
tinue  to  be  valid,  that  results  of  decisions  have  not 
taken  the  program  in  an  unanticipated  direction,  and 
that  the  plotted  course  continues  to  be  directed 
toward  accomplishment  of  the  program  goals.  The 
four  keys  to  a  successful  program  are  a  recognized 
need,  an  acquisition  strategy  that  makes  sense, 
management  commitment  to  include  funding  stabil¬ 
ity,  and  program  follow-through. 

Footnotes 

1.  Previously  DOD  Directive  5000.1  did  not  address  Joint  Service  Pro¬ 
gram  Management.  This  void  necessitated  the  Joint  Logistics  Com¬ 
manders  memorandum  of  agreement  which  was  subsequently  pro¬ 
mulgated  as  a  joint  regulation  (Joint  Air  Force  Systems  Command/Air 
Force  Logistics  Command/Army  Materiel  Command/Naval  Material 
Command  Regulation,  “Management  of  Multi-Service  Systems/Pro- 
jects/Programs,”  AFSC/AFLC  R  800-2,  AMC  R  70-59/NAVMATINST 
5000. 10A).  The  29  March  1982  issue  of  DOD  Directive  5000.1  on  Major 
Systems  Acquisition  does  include  policy  direction  on  Joint/Multi-Service 
Program  Management.  Because  of  this,  the  Service  regulations  cited 
above  are  being  reviewed  for  possible  cancellation,  but  procedural 
guidance  is  included  herein. 

2.  Report  of  the  Secretary  of  Defense  to  the  Congress  on  the  FY  1981 
Authorization  Request  and  FY  1981-1985  Defense  Programs,  p.  284. 
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CHAPTER  5 
Program  Review 


This  chapter  discusses  the  series  of  reviews  by  suc¬ 
cessively  higher  echelons  of  authority  at  specified 
points  in  the  acquisition  of  a  military  system.  The 
purpose  of  this  process  is  to  allow  a  balanced  assess¬ 
ment  of  the  risks  associated  with  a  program  at  the 
completion  of  a  well-defined  development  stage. 
Whatever  this  assessment  is  called— DSARC, 
NSARC,  ASARC,  AFSARC,  In-Process  Review,  CNO 
Executive  Board  (CEB)  Review,  Command  Assess¬ 
ment  Review,  etc.— its  fundamental  objective  is  to 
ensure  that  all  areas  of  uncertainty  are  carefully  con¬ 
sidered  before  a  commitment  is  made  to  proceed  to 
the  next  stage.  These  areas  of  uncertainty  may  in¬ 
clude: 

—Mission  Uncertainty:  Does  the  threat,  as  orginally 
assessed,  still  exist?  Does  the  mission  requirement 
adequately  identify  and  balance  or  mitigate  the 
threat? 

—Technical  Uncertainty:  Are  the  technical  objec¬ 
tives  of  the  system  feasible  with  respect  to  the  time 
and  resources  available  to  be  expended? 

—Program  Uncertainty:  Is  the  acquisition  manage¬ 
ment  strategy  consistent  with  program  goals  and 
resources? 

—Background  Uncertainty:  What  are  the  factors  ex¬ 
ternal  to  the  program,  e.g.,  change  in  national  goals, 
change  in  political  or  economic  climate,  change  in 
DOD  or  service  policy,  which  can  affect  the  program? 
Are  there  impacts  consistent  with  program  objectives 
and  resource  commitment? 

—Logistics  Uncertainty:  Will  the  system  be  support¬ 
able  at  deployment  under  the  logistics  philosophy 
and  strategy  in  use? 

These  reviews  are  scheduled  exclusively  according 
to  the  completion  of  specific  program  phases.  They 
are  conducted  independently  of  the  planning,  pro¬ 
gramming,  and  budgeting  process.  They  do  not  seek 
to  assign  relative  precedence  among  several  pro¬ 
grams,  but  rather  to  look  at  the  issues  of  only  one 
program.  Have  uncertainty  levels  at  the  particular 
stage  of  development  been  reduced  sufficiently  to 
allow  the  system  to  enter  the  next  phase? 


Levels  of  Program  Review 1 

During  mission  conceptualization  and  requirement 
generation,  an  estimate  must  be  made  of  the  impor¬ 
tance  and  urgency  of  the  prospective  program  and  of 
the  costs  involved  in  bringing  it  to  fulfillment.  These 
parameters  will  determine  the  level  of  formal  OSD 
and  service  management  attention.  Currently,  fund¬ 
ing  thresholds  are  set  for  programs  requiring  submis¬ 
sion  of  a  JMSNS  and  Secretary  of  Defense  approval 
at  decision  milestones,  with  OSD  discretionary 
authority  retained  to  control  less  costly,  but  impor¬ 
tant  or  urgent  programs.  Programs  not  managed  in 
the  “major  program’’  category  are  managed  accord¬ 
ing  to  the  precepts  of  the  major  program  acquisition 
directives,  but  by  service-unique  methods. 

Department  of  Defense  Directive  5000.1  defines 
decision  milestones  for  major  acquisition  programs 
as  shown  in  Figure  5-1.  Procedures  are  prescribed  in 
Department  of  Defense  Instruction  5000.2  and  sever¬ 
al  other  sources.  At  each  milestone  I  and  II,  the 
Defense  Systems  Acquisition  Review  Council 
(DSARC)  reviews  two  documents  updated  specifically 
for  that  milestone:  the  decision  coordinating  paper 
(DCP),  and  the  integrated  program  summary  (IPS). 
The  DSARC’s  recommendation— proceed/alter/ 
cancel — is  forwarded  by  the  Defense  Acquisition  Ex¬ 
ecutive  (DAE)  to  the  Secretary  of  Defense  for  ap¬ 
proval  in  the  form  of  a  Secretary  of  Defense  Decision 
Memorandum  (SDDM).  The  latter  document  pro¬ 
vides  not  only  the  basic  decision  but  also  updates 
goals  and  thresholds  for  the  program. 

The  Deputy  Secretary  of  Defense  April  30,  1981 
Memorandum  “Improving  the  Acquisition  Process” 
changes  the  SecDef  decision  milestones.  It 
“  . .  .  reduces  the  SecDef  decision  milestones  to  two, 
but  ensures  full  SecDef  involvement  in  major  pro¬ 
gram  initiation,  and  improved  program  definition  for 
program  go-ahead.  The  first  decision  point,  “Re¬ 
quirements  Validation:  (equivalent  to  combination  of 
Zero  and  One),  serves  as  full  DSARC/SecDef  review 
and  approval  of  major  program  initiation  including 
threat,  weapons,  concept,  risk  and  schedule,  readi¬ 
ness,  and  affordability  goals.  At  this  point  a  specific 
“not-to-exceed”  dollar  threshold  is  established  which 
sets  the  funding  to  carry  the  program  through  Con- 
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Figure  5-1 

DSARC  MILESTONES 


DEFINE— SECDEF  conducts  a  review  at  specific  points  in  the  acquisition  process  and  makes  decisions  on 
issues  associated  with  the  program. 

BACKGROUND  —  Previously  there  were  four  discrete  SECDEF  decision  points. 
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—  Alternatives  presented  to  determine  the  number  of  SECDEF  reviews. 


DESCRIPTION  OF  —  Decision  was  made  to  reduce  SECDEF  decision  milestones  to  two. 
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—  Requirement  Validation  Milestone  includes: 

—  Review  and  approval  of  major  program  initiation  including  threat,  weapons  con¬ 
cept,  risk  and  schedule,  readiness,  and  affordability  goals. 

—  “Not  to  Exceed"  dollar  thresholds  for  program  at  second  SECDEF  decision  point. 

—  Goals  to  be  achieved  by,  and  timing  of  second  SECDEF  milestone. 

—  Program  Go  Ahead  milestone  includes: 

—  SECDEF  review  and  approval  of  Service  proposed  actions  to  include  Full-Scale 
Development  and  Production,  T&E,  Support  and  Readiness,  and  total  acquisition 
strategy. 

—  Concurrency  with  Preliminary  Design  Review. 


ADVANTAGES  —  Reduces  administrative  burden  by  fewer  OSD  reviews 
—  Front-end  process  is  speeded. 

—  Review  levels  linked  to  major  expenditure  increases. 

—  Program  commitment  is  delayed  until  program  technical,  performance,  and  cost  fac¬ 
tors  are  more  accurately  determined. 

—  More  efficient  transition  between  development  and  production. 

—  Services  have  more  responsibility  for  their  own  programs. 
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cept  Validation  and  early  Full-Scale  Development  ac¬ 
tivity  up  to  the  second  decision  point,  “Full-Scale 
Development  and  Production.”  The  goals  to  be 
achieved  by,  and  the  timing  of  the  second  SecDef 
decision  point  are  defined  at  the  first  decision  point. 

The  Program  Go-Ahead,  second  SecDef  decision 
point,  occurs  somewhat  later  than  Milestone  II  in  a 
“normal”  program  schedule.  The  timing  of  this  deci¬ 
sion  point  is  flexible,  depending  on  the  program’s  ap¬ 
proved  acquisition  strategy.  SecDef  retains  source 
veto/ disapproval  of  a  Service  proposed  action  and 
program  plans  which  shall  include  Full-Scale 
Development  and  Production,  the  program  plan  for 
Test  and  Evaluation,  Support  and  Readiness,  and 
the  total  acquisition  strategy. 

Service  Secretary  if  there  are  no  major  changes  to 
the  program  approved  at  the  second  decision  point 
by  the  SecDef. 

Each  ongoing  major  program  will  be  reviewed  to 
determine  which  programs  will  follow  this  new  se¬ 
quence  of  milestones.  Currently  planned  Milestone 
III  programs  are  being  reviewed  to  determine  which 
reviews  should  be  held  at  OSD  and  which  should  be 
delegated  to  the  services.  Figure  5-1  compares  the 
old  and  the  new  milestones. 

Whereas  Department  of  Defense  Directive  5000. 1 
and  Instruction  5000.2  specify  requirements  for  the 
services’  handling  of  major  acquisition  programs,  they 
do  not  delineate  procedures  for  less-than-major  pro¬ 
grams.  Tables  5-1  through  5-4  summarize  the  cate¬ 
gories,  review  processes,  and  authority  levels  em¬ 
ployed  by  the  services  for  all  acquisition  programs. 

Special  Problems  of  Joint  Program  Review 

Joint  programs  may  present  special  problems 
because  of  the  need  to  satisfy  the  internal  review  re¬ 
quirements  of  all  participating  services.  Each  of  the 
services  has  implemented  Department  of  Defense  In¬ 
struction  5000.2  differently,  as  is  apparent  from  ex¬ 
amination  of  their  individual  DCP  processing  instruc¬ 
tions.  One  quickly  sees  that  the  echelon  by  which 
procedures  are  prescribed  is  different  and  that  the 
currency  of  instruction  and  level  of  detail  of  the  rele¬ 
vant  documents  are  also  different. 

Figures  5-2  through  5-5  display  the  hurdles  major 
programs  must  clear  within  OSD  and  the  individual 
service  staff  hierarchies  and  secretariats.  The  source 
for  each  process  is  included  with  the  Figure. 
However,  one  must  recognize  that  these  sterile  flow 
charts  do  not  indicate  all  the  coordination  required 
to  bring  about  a  successful  milestone  review.  Nor  do 
these  figures  suggest  internal  program  management 
office,  program  sponsor  office,  or  Office  of  the  Under 
Secretary  of  Defense  for  Research  and  Engineering 


action  officer  staff  routines.  In  fact,  more  is  required 
of  the  joint  program  manager  than  an  understanding 
of  the  written  procedures  alone,  for  they  are  often 
modified.  Usually  the  key  individual  in  a  review  proc¬ 
ess  is  also  the  key  person  in  changing  written  re¬ 
quirements.  His  own  staff  organization  may  already 
be  integrating  draft  directive  requirements,  an  oral 
requirement,  and  a  DOD  or  service  agency  require¬ 
ment  which  may  take  months  to  be  incorporated  into 
print.  For  example,  9  months  elapsed  between  the 
promulgation  of  Office  of  Management  and  Budget 
(OMB)  Circular  A-109  and  publication  of  the  imple¬ 
menting  DOD  directives.  It  was  not  until  22  months 
after  the  promulgation  of  Department  of  Defense 
Directive  5000.1  (March  1980)  that  all  the  services 
had  officially  implemented  the  new  requirements. 

Congressional  staffs,  the  OMB  and  the  Defense 
Acquisition  Executive  are  aware  of— or,  indeed,  have 
made— certain  new  requirements  to  the  DSARC 
process.  In  the  4  plus  years  that  have  elapsed  since 
the  initial  promulgation  of  Department  of  Defense 
Directive  5000.1  and  Instruction  5000.2,  new 
policies  have  been  developed  and  integrated  into  the 
program  review  process.  Among  these  is  a  new  re¬ 
quirement  that  the  DCP  include  an  annex  which  ad¬ 
dresses  the  program  from  the  standpoint  of  NATO 
Rationalization,  Standardization  and  Interoperability 
(RSI).  In  some  cases,  programs  have  successfully 
completed  a  number  of  service  review  steps,  only  to 
require  the  time-consuming  re-analysis  of  the  Project 
Management  Plan  (or  Joint  Development  Plan) 
against  the  complex,  and  often  not  very  well 
understood,  RSI  requirements.2 

Although  burdened  with  parallel  or  overlapping 
review  requirements,  a  joint  program  manager  still 
has  more  assistance  available  to  him  than  the  single¬ 
service  program  manager.  He  should  realize  that  the 
service  staffs  and  OSD  not  only  need  information, 
but  can  provide  it  as  well.  A  free  flow  of  information 
will  be  mutually  supportive,  and  the  following  offices 
are  likely  participants  in  any  such  exchange: 

Army:  The  appropriate  Department  of  the  Army 
System  Coordinator  (DASC)  in  the  Office  of  the 
Deputy  Chief  of  Staff  for  Research,  Development  and 
Acquisition  (DCSRDA).  (Code:  DAMA-  ) 

Navy:  The  appropriate  Deputy  Chief  of  Naval  Opera¬ 
tions  (DCNO)  or  Director  who  is  the  program  spon¬ 
sor: 

OP-02  Submarine  Warfare 
OP-03  Surface  Warfare 
OP-05  Air  Warfare 
OP-094  Command  and  Control 
OP-095  Naval  Warfare 
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Figure  5-2 

DCP  PROCESSING:  DOD  INSTRUCTION  5000.25 
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-  6  MONTHS 


-  3  MONTHS 


-  2  MONTHS 


-15  WORKDAYS 


-15  WORKDAYS 


-10  WORKDAYS 


-  5  WORKDAYS 


-  3  WORKDAYS 


0 


+  15  WORKDAYS 


0CAIG— COST  ANALYSIS  IMPROVEMENT  GROUP 

@  DIR.  DEF.  T&E— DIRECTOR  OF  DEFENSE  TEST  AND  EVALUATION 
@  M&LA— MANPOWER  &  LOGISTICS  ANALYSIS 
®  DIA— DEFENSE  INTELLIGENCE  AGENCY 
®  AS  OF  1  DECEMBER  1981 
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Figure  5-3 

ARMY  DCP  PROCESSING:  ODCSRDA  REG 


.  15-14 
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Figure  5-4 

NAVY  DCP  AND  DSARC  REVIEW  PROCESS: 
OPNAVINST  5000.46 
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Figure  5-5 

AIR  FORCE  DCP  PROCESSING: 

DRAFT  AIR  FORCE  HOI— PROCEDURES  FOR  AFSARC 


6  MONTHS 

BEFORE 

DSARC 


2  MONTHS 

BEFORE 

AFSARC 


10  DAYS 

BEFORE 

AFSARC 
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Table  5-1 

ARMY  PROGRAM  REVIEW  BY  ACQUISITION  CATEGORY 


TYPE  OF 
ACQUISITION 

PRIMARY  CRITERIA 

LEVEL  OF 
APPROVAL 

TYPE  OF 
REVIEW 

DECISION 

RECORDING 

DOCUMENT 

DOD-designated 

Major  Program 

Program  of  significant 
interest,  importance,  or 
impact.  Threshold  $200M 
RDTE  or  $1  B  procure¬ 
ment  costs. 

SECDEF 

DSARC 

ASARC 

SCP 

Army-designated 
Major  Program 
Category  1 

As  directed  by  ASARC 
Chairman  but  not  DOD- 
designated  major 
program. 

Secretary 
of  Army 

ASARC 

Army  Program 
Memorandum 
( APM) 

Non-Major 

Program  Category  2 

As  directed  by 

DSCRDA. 

HQDA 

(DCSRDA) 

In  Process 

Review 

(IPR) 

Acquisition 

Plan  (AP) 

Non-Major 

Program  Category  3 

$0-75M  RDTE  and 
$0-300M  procurement 
costs. 

DARCOM 

IPR 

AP 

Non-Major 

Program  Category  4 

None  of  the  above. 

System  R&D 
Command 

IPR 

AP 

Table  5-2 

NAVY  PROGRAM  REVIEW  BY  ACQUISITION  CATEGORY 


ACAT  1 

2S 

2C 

3 

4 

Decision  Authority 

SECDEF 

SECNAV 

CNO 

DCNO/DMSO 

CNM  (or  designee) 

Decision  Forum 

DSARC 

DNSARC 

CEB  or  ARC 

Sponsor  Review 

ARB  or  other 

NMC  Review 

ACAT  Criteria 

S200M  R&D  or 

SIB  procurement 

S100M  R&D  or 

S500M  Production 
(under  consideration) 

CNO  discretion 

Military  characteristics 
of  ship  or  aircraft 
significantly  affected 

Documentation 

Required 

JMSNS-program 

initiation 

SCP-lst  milestone 
DCP/I  PS-2nd 
milestone  &  TEMP 

Mini-NDCP 

& 

TEMP 

Mini-NDCP 

& 

TEMP 

TEMP 

(&  mini-NDCP 
if  needed) 

As  prescribed  by 

CNM  (usually 
mini-N  DCP ) 

Milestone  Review 

•  Initiation 

SECNAV 

SECNAV 

CNO 

CNO  sponsor 

CNO  sponsor 

•  Milestone  1 

SECDEF 

SECNAV 

CNO 

Sponsor 

CNM  (or  designee) 

•  Start  of  FSED  if  not 
concurrent  with 
Milestone  2 

SECNAV 

•  Milestone  2 

SECDEF 

SECNAV 

CNO 

Sponsor 

CNM  (or  designee) 

•  Milestone  3 

SECNAV 

SECNAV 

CNO 

Sponsor 
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Table  5-3 

AIR  FORCE  PROGRAM  REVIEW  BY  ACQUISITION  CATEGORY 


TYPE  OF 
ACQUISITION 

PRIMARY  CRITERIA 

LEVEL  OF 
APPROVAL 

TYPE  OF 
REVIEW 

DECISION 

RECORDING 

DOCUMENT 

DOD-designated 

Major  Program 

SECDE  F-designated. 

$200M  RDTE  or  $1B  pro¬ 
curement  costs. 

SECDE  F 

DSARC 

AFSARC 

SCP 

Air  Force-designated 

Major  Program 

SEC  Air  Force-designated 

SECAF 

AFSARC 

AF  DC P 

Non-Major  Program 

None  of  the  above 

See  NOTE 
below. 

NOTE:  in  addition  to  the  program  milestone  reviews  for  DSARC/ AFSARC  level  programs,  and  solely  for  programs  whose  interest  or 

fh'0Dl^/cD^SUffl*KienAtlcWarrant  DSARC/AFSARC  attention,  the  Air  Force  employs  periodic  (vice  program  milestone)  reviews,  at  which 
the  PM/SPO  or  the  AFSC  Systems  Officer  presents  the  status  of  programs  as  follows: 


—Highest  Level: 

—AFSC  Level: 

—  Product  Division  Level 


SECAF  Program  Review  (SPR) 

Program  Assessment  Review  (PAR)  by  Air  Staff 
Command  Assessment  Review  (CAR) 

Management  Assessment  Review  (MAR) 

(generally  less  than  $2M  to  achieve  program  objectives) 


m  genera|,  SPR/PARs,  CARs,  and  MARs  are  held  quarterly,  with  monthly  updates  to  the  SPR/PAR,  CAR,  MAR  document  The  level  at 
which  a  program  will  be  reviewed  is  more  discretionary  than  cost  influenced 


Table  5-4 

MARINE  CORPS  PROGRAM  REVIEW  BY  ACQUISITION 
CATEGORY 


TYPE  OF 
ACQUISITION 

PRIMARY  CRITERIA 

LEVEL  OF 
APPROVAL 

TYPE  OF 
REVIEW 

DECISION 

RECORDING 

DOCUMENT 

DOD-designated 

Major  Program 

SECN  AV-designated. 
$200M  RDTE  or  $1B 
procurement  costs. 

SECDE  F 

DSARC 

SCP 

Navy-designated 
Major  Program 

SECN  AV-designated 
$75M  RDTE  or  $300M 
procurement  costs 

SECNAV 

DNSARC 

Navy  (NDCP) 

Marine  Corps- 
designated  Major 
Program 

CMC-designated.  $5M 
RDTE  or  $20M  procure¬ 
ment  costs. 

CMC 

MSARC 

Acquisition 

Decision 

Memorandum 

(ADM) 

Marine  Corps 
Non-Major  Program 

None  of  the  above. 

Chief  of  Staff 
(MCHQ) 

In  Process 
Review 

ADM 
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Marine  Corps :  The  appropriate  Development  Pro¬ 
gram  Officer  (DPO)  in  the  Office  of  the  Deputy  Chief 
of  Staff  for  Research,  Development,  and  Studies 
(MC-RD). 

Air  Force:  The  appropriate  program  element 
monitor  (PEM)  in  the  Office  of  the  Deputy  Chief  of 
Staff,  Research  Development  and  Acquisition 
(AF/RD)  or  Deputy  Chief  of  Staff,  Logistics  and 
Engineering  (AF/LE). 

Department  of  Defense:  The  appropriate  action  of¬ 
ficer  in  the  Office  of  the  Under  Secretary  of  Defense 
for  Research  and  Engineering. 

DASCs,  program  sponsors,  DPOs,  PEMs  and  ac¬ 
tion  officers  may  have  several  projects  to  monitor,  or 
only  one.  Army  DASCs  and  Air  Force  PEMs  are  like¬ 
ly  to  have  a  single  program.  The  Navy  program  spon¬ 
sor,  the  Marine  Corps  (DPO),  and  the  USDRE  action 
officers  are  likely  to  monitor  many  projects  in  their 
specific  warfare  disciplines.  Consequently,  more  ini¬ 
tiative  is  required  to  coordinate  with  these  Navy, 
Marine  Corps  and  USDR&E  points  of  contact. 

The  joint  program  manager’s  relationships  with 
these  monitors  should  be  as  open  as  possible.  They 
are  often  called  upon  to  make  planning,  program¬ 
ming  or  resource  allocation  recommendations  to 
service  secretariat  or  OSD  decision-makers.  While 
the  program  manager  is  concerned  about  trade-offs 
among  the  competing  demands  of  system  perform¬ 
ance,  cost,  and  schedule,  they  are  answering  queries 
and  providing  information  and  recommendations 
that  can  enhance  or  undo  the  program  acquisition 
strategy.  Prompt  responses  to  their  requests  for  in¬ 
formation  will  make  successful  accomplishment  of 
the  program  reviews  much  easier. 

Furthermore,  the  Pentagon  monitors  associated 
with  the  incipient  joint  program  are  likely  to  be  much 
more  knowledgeable  about  the  various  service-OSD 
interfaces  than  the  program  manager.  Many  of  them 
will  have  processed  MENS,  DCPs,  and  SDDMs. 
Some  will  have  experience  with  the  incumbent  prin¬ 
cipal  decision-makers.  They  will  be  the  sources  of  the 
understanding  of  the  details  behind  the  generalized 
DOD  acquisition  documents  and  of  the  areas  where 
promulgated  directives  are  no  longer  current.  Some 
will  have  a  detailed  internal  staff  instruction  which 
provides  for  check  points  and  guidance  during  the 
review  process.  One  of  them  may  be  drafting  a  revi¬ 
sion  to  a  significant  directive  which,  though  not  yet 
promulgated,  comprises  a  much  more  up-to-date 
document  than  the  official  one.  (There  probably  will 
always  be  a  draft  Department  of  Defense  Directive 
5000.1  or  Instruction  5000.2  in  circulation  “for  com¬ 
ment”  or  “for  coordination.”)  The  new  joint  program 


manager  can  receive  the  benefit  of  this  “insider” 
knowledge  only  through  having  built  a  cooperative 
relationship  with  these  most  important  people. 

To  sum  up,  the  joint  program  manager  should  do 
his  homework  and  establish  good  working  relation¬ 
ships  with  his  Pentagon  monitors  so  he  can  use  the 
joint  review  process  to  gain  support  for  his  program. 

Footnotes 

1.  Shortly  before  the  Joint  Commander  signed  this  guide,  the  Deputy 
Secretary  of  Defense,  Frank  C.  Carlucci  signed  DOD  Directive  5000.1  on 
29  March  1982.  Also,  on  12  April  1982,  the  Under  Secretary  of  Defense, 
Research  and  Engineering,  Richard  D.  DeLauer,  promulgated  by 
memorandum  major  defense  system  acquisition  program  documentation 
format.  Because  of  the  close  proximity  of  these  events,  the  policy  and  re¬ 
quirements  of  these  documents  may  not  be  fully  included  in  this  guide. 
Accordingly,  the  reader  should  seek  additional  guidance  from  these 
source  documents. 

2.  DSMC  has  prepared  a  NATO/RSI  Guide. 
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CHAPTER  6 
Organization  and 
Staffing 


Program  Structure 

There  is  no  standard  for  joint  programs.  The  pro¬ 
gram  structure  depends  on  the  size  and  goals  of  the 
program,  the  phase  of  the  program  in  the  acquisition 
process,  the  desired  relationship  among  the  services, 
the  acquisition  strategy  for  the  program,  and  the  role 
of  OSD  in  the  program.  There  is  a  wide  variety  of 
joint  program  organizations.  The  joint  program  man¬ 
ager  must  tailor  his  organization  to  the  mission, 
functional  relationships  with  the  executive  and  par¬ 
ticipating  Services,  and  extent  of  responsibilities  of 
the  joint  program  office. 

Joint  programs  normally  require  more  personnel 
than  typical  single-service  programs  due  to  much 
more  coordination  and  the  need  for  being  aware  of 
participating  services’  efforts,  as  well  as  the  executive 
service  program  efforts  requires  more  diverse  skills 
and  specialities  resident  in  the  joint  program  office. 
Grade  structure  of  the  joint  program  office  tends  to 
be  higher  because  of  increased  responsibilities,  and 
because  the  tasks  require  considerable  knowledge  of 
how  each  service  operates.  This  is  especially  true  in 
the  logistics  areas,  as  personnel  tend  to  be  special¬ 
ized  and  many  problems  in  inter-service  logistics  are 
manpower  intensive.  Current  formal  and  service 
training  is  focused  toward  the  parent  service  and 
therefore  there  is  a  considerable  learning  time,  6-8 
months,  before  an  officer  or  civilian,  knowledgeable 
in  his  service,  can  be  effective  in  representing 
another  service  or  joint  service.  Business  manage¬ 
ment  requires  augmentation  to  maintain  the  addi¬ 
tional  records,  prepare  the  separate  briefings  and  the 
additional  budget  exercises  required  of  the  other 
services. 

Organization  of  the  Joint  Service  Program 
Office 

A  joint  program  is  usually  initiated  based  upon 
direction  from  the  Deputy  Secretary  of  the  Defense 
(Dep  Sec  Def)  or  Under  Secretary  of  Defense  for 
Research  and  Engineering  (USDR&E)  in  the  form  of 
a  memorandum  designating  a  lead  or  executive  serv¬ 
ice  and  directing  that  service  to  charter  the  joint  pro¬ 
gram.  Normally,  the  lead  or  executive  service  pro¬ 
vides  the  program  manager,  but  recently  the  Dep  Sec 


Def,  in  an  8  May  81  memorandum,1  directed  the 
Army  to  be  “the  contracting  agency  with  overall  ac¬ 
quisition  responsibility”  with  the  USMC  to  provide  at 
a  minimium  the  program  manager.  It  should  be 
noted  that  joint  service  organization  involves  con¬ 
tinuous,  dynamic  and  complex  processes  with  sub¬ 
stantial  areas  for  dispute.  DOD  policies  and  regula¬ 
tions,  including  AFLC/AFSC  R  800-2/AMRC 
70-59/NAVMATINST  5000. 10A,  provide  only  the 
basic  framework  to  resolve  interservice  issues,  usual¬ 
ly  through  compromise  and  negotiations  of  the 
memorandum  of  agreement  (MOA)2  and  its  annexes 
between  the  services.  A  listing  is  provided  at  Appen¬ 
dix  F  of  current  joint  service  programs. 

Single-Service  Program  Office 

Many  joint  programs,  especially  small  programs, 
are  joint  only  because  their  goals  are  to  satisfy  joint 
requirements.  For  the  most  part,  these  programs  are 
structured  and  managed  as  they  would  be  if  they 
were  single-service  programs.  The  participating  serv¬ 
ice  may  assign  a  liaison  officer  or  representative  to 
the  program  office,  or  it  may  simply  monitor  the  pro¬ 
gram.  Normally,  the  interests  of  the  Executive  Serv¬ 
ice  dominate  the  program. 

Jointly  Staffed  Program  Office 

The  term  “joint  program”  usually  conjures  up  the 
image  of  a  single,  jointly  staffed,  program  office.  The 
Executive  Service  provides  the  program  manager, 
most  of  the  program  management  staff,  and  admini¬ 
strative  support.  The  participating  services  each  con¬ 
tribute  a  deputy  program  manager  and  other  military 
officers  to  the  program  management  staff.  In  prac¬ 
tice,  most  joint  programs  are  not  structured  this  way; 
there  are  few  jointly  staffed  program  offices. 
However,  the  practice  is  becoming  more  common 
and  seems  to  be  the  joint  program  structure  pre¬ 
ferred  by  the  services.  Though  not  explicit  about  pro¬ 
gram  structure,  the  Joint  Logistics  Commanders’ 
Memorandum  of  Agreement  on  “Management  of 
Multi-Service  Programs/Projects”  assumes  the  crea¬ 
tion  of  a  jointly  staffed  program  office,  and  most  pro¬ 
grams  structured  that  way  follow  the  guidelines  of  the 
MOA. 
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Multiple  Program  Offices 

A  surprising  number  of  joint  programs  are,  in  fact, 
multiple  programs  or  projects  whose  activities  are 
coordinated.  The  degree  and  method  of  coordination 
vary  from  program  to  program,  as  does  the  principal 
source  of  program  direction.  Frequently,  the  OSD 
plays  some  direct  role  in  the  program’s  execution. 

As  one  might  suspect,  many  joint  programs  in  this 
category  have  unique  management  structures. 
Several  examples  of  these  structures  are  depicted  in 
Figure  6-1.  The  structure  shown  in  Figure  6-la 
might  be  considered  more  a  confederation  of  pro¬ 
gram’s  than  a  joint  program.  Each  service  manages  its 
own  program  but  exchanges  information  regularly 
with  the  other  services.  OSD  sometimes  orchestrates 
the  efforts,  dividing  responsibilities  among  the  serv¬ 
ices  to  eliminate  duplication  or  to  ensure  that  alter¬ 
natives  are  explored.  OSD  direction  and  inter-service 
interactions  are  minimal. 

The  opposite  is  true  of  the  joint  program  structure 
depicted  in  Figure  6-lh.  In  it,  a  jointly  staffed  OSD 
program  office  has  been  created.  Subordinate  pro¬ 
ject  offices  are  staffed  and  administratively  supported 
by  the  services.  Program  direction  is  provided  by 
OSD. 

Figure  6-1  c.  shows  a  program  structure  which  is 
similar  to  that  in  Figure  6-lh._  The  difference  is  that 
instead  of  creating  an  OSD  program  office,  one  of 
the  services  has  been  tasked  to  provide  overall  pro¬ 
gram  management.  Individual  projects  are  managed 
by  the  services.  Central  control  is  less  extensive  than 
that  exercised  by  an  OSD  program  office,  concen¬ 
trating  primarily  on  requirements,  funding,  and  con¬ 
figuration. 

Figure  6-ld  depicts  another  variation  of  the  struc¬ 
ture  of  Figure  6-lb.  Direction  to  the  joint  program 
office  is  provided  by  an  executive  committee  com¬ 
prised  of  senior  representatives  from  each  of  the 
services  participating  in  the  program,  as  well  as  from 
OSD.  Such  an  arrangement  tends  to  moderate  OSD 
control  of  the  program,  yet  still  provide  strong,  cen¬ 
tral  program  direction. 

Program  Office  Organization 

There  are  two  basic  alternatives  for  program  office 
organization.  One  is  to  include  on  the  program 
management  staff  all  functional  specialists  needed 
for  program  execution,  essentially  establishing  a  self- 
contained  organization.  The  other  is  to  restrict  the 
program  management  staff  to  a  cadre  of  managers 
who  draw  functional  support  from  the  parent  organi¬ 
zation.  This  latter  is  commonly  called  a  matrix  orga¬ 
nization.  Most  program  management  organizations 


are  neither  completely  self-contained  nor  completely 
matrix,  but  a  mixture  of  the  two.  Large,  high-priority 
programs,  especially  in  the  Air  Force  and  Navy,  tend 
more  toward  the  self-contained  program  office 
organization,  depending  less  on  small  outside  matrix 
resources;  low-priority  programs  tend  more  toward 
the  matrix  type.  The  joint  staff  manning  effort  should 
include  a  configuration  of  agreed-to  position  types 
and  numbers,  their  configuration  and  estimated 
duration  of  service.  The  personnel  requirements 
should  be  specified  as  military  or  civilian  and  the  serv¬ 
ice  providing  the  resource.  Sufficient  time  must  be 
allowed  in  filling  civilian  requirements. 

Joint  programs  normally  follow  the  organization 
practice  of  the  Executive  Service.  However,  in  a 
jointly  staffed  program  office,  it  is  normally  desirable 
to  include  on  the  program  management  staff  as  much 
functional  expertise  as  practicable.  Supporting  a 
joint  program  that  has  the  active  participation  of  two 
or  more  services  is  an  extraordinary  task.  It  is  time 
consuming.  Many  of  the  services’  normal  procedures 
must  be  modified  or  abandoned  in  favor  of  pro¬ 
cedures  better  suited  to  the  program’s  needs.  A  func¬ 
tional  specialist  who  is  assigned  full-time  to  the  pro¬ 
gram  management  staff  is  more  likely  to  share  fully  in 
the  spirit  and  objectives  of  the  program  and  to  cling 
less  fervently  to  service-peculiar  procedures  than  is 
one  who  is  working  part-time  for  the  program. 

A  complicating  factor  in  the  organization  of  a 
jointly  staffed  program  office  is  the  assignment  of 
responsibilities  to  personnel  from  the  participating 
services.  The  fact  that  the  program  office  is  jointly 
staffed  is  evident  of  the  participating  services’  desires 
to  influence  the  program.  However,  it  should  be  clear 
from  the  organization  of  the  program  office,  as  well 
as  stated  in  the  charter,  that  the  participating  serv¬ 
ices’  representatives  share  responsibility  for  success 
of  the  joint  program,  they  are  not  merely  represent¬ 
ing  their  services’  interests.  To  accomplish  this,  the 
joint  program  manager  should  organize  his  staff  and 
allocate  key  positions  among  the  services  such  that  a 
balance  of  responsibility,  authority,  and  influence  is 
maintained.  The  senior  representatives  from  the  par¬ 
ticipating  services  must  be  in  the  chain-of-command, 
directly  subordinate  to  the  program  manager. 
Sometimes  this  may  require  creating  one  or  more 
positions  for  principal  deputy  program  managers. 
Creating  extra  positions  is  preferable  to  rotating  one 
position  among  the  participating  services  or  to 
slighting  the  interests  of  one  by  subordinating  its 
representative  to  the  other  services’. 
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Figure  6-1 

STRUCTURES  OF  JOINT  PROGRAMS 
HAVING  MULTIPLE  PROGRAM  OFFICES 


Figure  6-la 


Figure  6-lc 


Personnel  Selection 

One  of  the  joint  program  manager’s  greatest 
challenges  is  creating  an  esprit  de  corps  within  the 
program  office.  There  are  bound  to  arise  situations 
in  which  the  services’  interests  conflict.  Success  of 
the  program  then  depends  on  having  program  man¬ 
agement  staff  personnel  who  are  committed  to 
resolving  the  problem,  rather  than  provoking  con¬ 
frontations.  Representatives  from  the  participating 
services  must  be  expected  to  guard  their  services’  in¬ 
terests;  that  is  why  they  are  assigned  to  the  program 
office.  But  their  attitude  and  approach  must  he 
dedicated  to  success  of  the  program. 

The  joint  program  manager  wants  on  his  staff  the 
same  type  people  who  are  wanted  on  every  staff: 
knowledgeable,  hard-working,  efficient,  and  loyal. 
More  than  others,  however,  the  joint  program 
manager  needs  people  who  can  work  well  with  others 
and  who  are  willing  to  explore  unique  solutions  to 
management  problems.  The  joint  program  staff  must 
be  creative,  flexible,  and  determined. 


OSD 


Figure  6-lb 


Figure  6-ld 


Selection  of  the  deputy  program  managers, 
especially  those  from  the  participating  services,  is 
particularly  important  to  the  joint  program  manager. 
Not  only  must  he  have  confidence  in  the  abilities  of 
his  deputies,  he  must  be  able  to  develop  a  good  work¬ 
ing  relationship  with  them.  Personality  conflicts, 
even  among  people  who  are  otherwise  competent, 
can  undermine  a  joint  program.  Before  accepting 
assignment  of  key  personnel,  the  program  manager 
should  interview  them,  discuss  program  objectives, 
management  approach,  and  management 
philosophy,  and  satisfy  himself  that  each  will  become 
a  part  of  a  good  management  team. 

Personnel  Evaluations 

As  a  general  rule,  each  person’s  performance 
should  be  evaluated  by  his  supervisor.  In  joint  pro¬ 
grams,  this  rule  can  be  followed  for  most  personnel. 
The  common  exception  is  for  military  officers  assign¬ 
ed  by  a  participating  service  to  a  jointly  staffed  pro¬ 
gram  office.  It  is  normally  considered  important  to  an 
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officer’s  career  for  his  performance  to  be  evaluated 
by  an  officer  of  his  own  service.  Therefore,  in  a  joint¬ 
ly  staffed  program  office,  the  participating  services’ 
senior  representatives  should  be  responsible  for 
evaluating  the  performances  of  officers  from  their 
services. 

The  program  manager,  however,  should  always 
evaluate  the  performances  of  the  participating  serv¬ 
ices’  senior  representatives,  even  if  they  are 
evaluated  also  by  the  participating  services. 


Footnotes 

1.  Deputy  Secretary  of  Defense  Memorandum,  Subj:  Mission  Ele¬ 
ment  Needs  Statement  (MENS)  for  the  Light  Armored  Vehicle  (LAV), 
dated  8  May  1981. 

2.  Previously  DOD  Directive  5000.1  did  not  address  Joint  Service 
Program  Management.  This  void  necessitated  the  Joint  Logistics  Com¬ 
manders  memorandum  of  agreement  which  was  subsequently  pro¬ 
mulgated  as  a  joint  regulation  (Joint  Air  Force  Systems  Command/Air 
Force  Logistics  Command/Army  Materiel  Command/Naval  Material 
Command  Regulation,  “Management  of  Multi-Service  Systems/Pro¬ 
jects/Programs,”  AFSC/AFLC  R  800-2,  AMC  R  70-59/NAVMATINST 
5000. 10A).  The  29  March  1982  issue  of  DOD  Directive  5000.1  on  Major 
Systems  Acquisition  does  include  policy  direction  on  Joint/Multi-Service 
Program  Management.  Because  of  this,  the  Service  regulations  cited 
above  are  being  reviewed  for  possible  cancellation,  but  procedural 
guidance  is  included  herein. 
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CHAPTER  7 
Financial 
Management 


Establishing  A  Sound  Financial 
(Business)  Base. 

Selection  and  assignment  of  an  experienced  and 
knowledgeable  Financial  Manager  is  essential  to  es¬ 
tablishment  of  a  sound  financial  base  for  a  Joint 
Service  Program.  Regardless  of  the  official  title — 
Fiscal  Manager,  Controller,  Financial  Manager  or 
Business  Manager— the  financial  management  re¬ 
sponsibilities  are  the  same.  They  are  pervasive,  en¬ 
compassing  planning  and  control  of  all  financial  mat¬ 
ters  relating  to  programming,  budgeting,  allocating, 
committing,  obligating,  expending  and  accounting  of 
funds  for  salaries,  for  example,  as  well  as  actual 
equipment  or  system  development.  The  financial 
manager  must  be  on  board  and  deeply  involved  in  fi¬ 
nancial  analysis  and  planning  needed  to  establish 
program  cost  estimates,  and  be  the  principal  archi¬ 
tect  on  preparing  the  Joint  Program  Funding  Plan. 
The  funding  plan  should  be  keyed  to  the  work  break¬ 
down  structure  and  master  schedule  prepared  by 
program  analysts  with  the  assistance  of  cost  analysis 
experts,  and  must  include  a  time-phased  profile  of 
funding  requirements  by  type  and  source.  The  plan 
must  lend  itself  to  ease  of  breakout  of  funds  by 
source— particularly  the  “other”  services  planned 
contribution  of  funds,  by  type.  Selection  and  assign¬ 
ment  of  a  competent  financial  manager  and  develop¬ 
ment  of  a  comprehensive  funding  plan  are  key- 
first— steps  in  establishing  a  sound  business  base  for 
the  Joint  Service  Program.  Accordingly,  the  first 
critical  task  that  must  be  accomplished  by  the  finan¬ 
cial  or  business  manager  is  development  of  the  fund¬ 
ing  plan. 

A  second  critical  task  will  be  to  establish  central 
control  of  all  funds  allocated  to  the  program,  regard¬ 
less  of  source,  purpose  or  ultimate  approved  use.  All 
obligational  authority  for  the  Joint  Service  Program 
should  be  transferred  to  the  Joint  Program  Office  or 
that  office’s  present  development/logistics  command, 
even  if  some  obligational  authority  is  returned  to  the 
participating  services.  The  Joint  Program  Office 
should  use  the  financial  management  and  accounting 
procedures  of  the  Executive  Service. 

Programming  and  budgeting  activities  also  should 
be  centrally  directed  by  the  Joint  Program  Manager. 
Although  the  programming  and  budgeting  processes 


in  all  the  services  follow  the  same  general  pattern 
and  schedule  established  by  the  Office  of  the  Secre¬ 
tary  of  Defense  (OSD),  practices  do  vary  from  service 
to  service.  Moreover  specific  practices  are  likely  to 
vary  from  year  to  year  within  any  service.  The  Joint 
Program  Manager  or  his  financial  manager  are  not 
advised  to  attempt  to  become  expert  in  the  service- 
to-service  variations.  Where  possible,  and  certainly 
in  the  case  of  a  large  program  office  staff,  financial 
experts  from  each  of  the  participating  services 
should  be  included.  When  staffing  authorizations  or 
lack  of  available  personnel  preclude  such  staffing, 
the  financial  manager  must  establish  and  exercise 
close  coordination  with,  and  obtain  timely  assistance 
of  controller  and  Headquarters  Staff  personnel  in  the 
participating  services.  Specific  points  of  contact  must 
be  established  and  working  relationships  cultivated 
to  ensure  quick  and  decisive  responses  to  financial 
management  matters.  Just  as  important  is  the  matter 
of  the  Joint  Program  Office  keeping  the  participating 
services  informed  (up-to-date)  on  financial  status- 
relating  to  allocation  commitment  and  obligation  of 
funds.  In  any  event,  the  Financial  Manager  should 
ensure  that  program  and  budget  submissions  are 
compatible  with  the  master  schedule  and  joint  pro¬ 
gram  funding  plan;  that  these  come  together  at  OSD 
as  a  joint  funding  requirement,  and  are  defensed 
before  OSD,  OMB  and  Congress  as  a  joint  program. 

Sharing  of  Funding  Responsibility 

Few  joint  programs  enjoy  single-source  funding. 
Funding  responsibility  for  most  joint  programs  is 
shared  by  the  Executive  and  Participating  Services. 
Whereas  joint  program  direction  often  emanates 
from  OSD,  funding  is  provided  by  the  services,  sub¬ 
ject  to  each  service’s  assessment  of  its  own  funding 
priorities. 

The  funding  arrangements  for  a  joint  program  are 
normally  defined  in  the  program  charter  or  in  a 
memorandum  of  agreement  (MOA)  between  the  serv¬ 
ices.  If  neither  of  these  is  possible,  the  funding  ar¬ 
rangements  should  be  defined  in  MOA  between  the 
joint  program  manager  and  each  of  the  services. 

The  formula  for  sharing  funding  responsibility 
varies  from  program  to  program.  Here  is  a  typical 
arrangement: 
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Research,  Development,  Test  and  Evaluation 
Funds.  Requirements  peculiar  to  one  service  are 
funded  by  the  sponsoring  service.  Funding  of  re¬ 
quirements  common  to  all  participants  is  either  pro¬ 
vided  entirely  by  the  Executive  Service  or  split 
among  participants  according  to  an  agreed  formula 
(e.g.,  proration  according  to  planned  procurement). 

Procurement  Funds.  Each  service  provides  funds 
to  meet  its  own  requirements.  Funding  of  common 
items,  such  as  data  and  software,  is  prorated  among 
participants. 

Operation  and  Maintenance  Funds.  Although 
Operation  and  Maintenance  (O&M)  funded  activities, 
such  as  repair,  rework,  modification,  etc.,  of  the 
deployed  system,  may  not  occur  until  after  the  dises¬ 
tablishment  of  the  joint  acquisition  program  office, 
the  joint  program  funding  plan  must  make  provision 
for  such  O&M  expenditures.  In  this  case,  a  formula 
for  proration  of  the  costs  among  deploying  services 
should  be  planned. 

Military  Personnel  Funds.  Each  service  bears  all 
costs  of  its  military  personnel  assigned  to  the  joint 
program  office. 

Military  Construction  Program  (MCP)  Funds.  A 
problem  common  to  many  complex  interservice  pro¬ 
grams  is  lack  of  adequate  planning  for  MCP  funds  for 
R&D  and  operational  deployment  facilities.  General¬ 
ly,  all  construction  in  excess  of  $I00K  per  facility 
must  be  funded  from  MCP  funds.  The  normal  lead 
time  for  programming  of  these  funds  is  3  years  before 
the  facility  is  needed;  some  facilities,  such  as  those 
supporting  some  types  of  new  ammunition,  may  re¬ 
quire  up  to  7  years.  Adequate  advance  planning, 
especially  for  unique  facilities,  can  eliminate  poten¬ 
tial  program  schedule  impacts  during  full-scale 
development. 

Avoiding  Funding  Problems 

To  minimize  the  possibility  that  one  service  may 
back  out  of  the  joint  program  (most  likely  when  the 
system  is  ready  for  production,  because  that  is  when 
large  sums  are  committed),  the  program  manager 
should  periodically  verify  that  the  users’  needs  re¬ 
main  as  stated  for  the  program.  If  the  user  interest  is 
weak,  chances  are  the  service  will  never  support  pro¬ 
duction.  To  get  a  clear  indication  of  user  interest,  it 
is  important  to  press  for  inclusion  of  procurement 
funds  in  the  outyears  of  the  Five  Year  Defense  Plan 
(FYDP). 

Even  when  firm  user  needs  exist,  there  is  always 
the  possibility  that  one  of  the  participants  may 
unilaterally  eliminate  or  reduce  its  number  of  pro¬ 
duction  units,  thereby  increasing  unit  price  to  the 
other  participants.  There  is  no  universal  solution  to 


this  problem.  However,  one  joint  program  manager 
was  able  to  avoid  the  problem  by  negotiating  a  joint 
program  procurement  commitment.  The  commit¬ 
ment  obligated  each  participant  to  procure  a  speci¬ 
fied  minimum  quantity  or  pay  the  increase  in  unit 
procurement  costs  suffered  by  the  other  participants 
because  of  reductions  in  the  total  quantity  of  units 
procured. 

An  arrangement  similar  to  a  procurement  commit¬ 
ment  can  also  be  used  to  resolve  funding  problems 
arising  from  engineering  changes  made  during  pro¬ 
duction.  During  development,  funding  of  changes 
usually  follows  the  pattern  established  for  funding  of 
total  program  research  and  development.  Changes  to 
meet  requirements  peculiar  to  one  service  are  funded 
by  the  service  sponsoring  the  change.  Other  changes 
are  funded  either  by  the  Executive  Service  or  on  a 
pro-rata  basis.  Whether  a  change  should  be  common 
or  service-peculiar  is  frequently  the  subject  of  heated 
debate,  but  once  that  issue  is  settled,  the  funding 
responsibility  is  clear.  Engineering  changes  made 
during  production  are  likely  to  pose  a  more  difficult 
problem,  since  changes  invariably  increase  unit  price 
and,  by  then,  the  services  have  already  established 
their  total  affordable  production  requirements.  If  one 
participant  does  not  want  the  change  and  cannot  af¬ 
ford  the  increase  in  unit  price,  the  program  may  be 
torn  between  foregoing  the  change  for  all  parties 
(perhaps  resulting  in  a  product  which  is  unacceptable 
to  one  service)  or  abandoning  the  common  con¬ 
figuration.  One  joint  program  manager  solved  such  a 
problem  by  persuading  the  participant  needing  the 
change  to  fund  the  increase  in  unit  price  to  the 
others,  thereby  incorporating  the  change  and  main¬ 
taining  a  common  configuration  at  no  additional  cost 
to  those  not  needing  the  change. 

Other  problems  in  joint  program  funding  frequent¬ 
ly  arise  from  differences  among  the  services  in  their 
uses  of  various  categories  of  funds  or  in  funding 
responsibilities  within  a  service.  There  is  no 
catalogue  of  such  differences  among  the  services, 
however  a  few  examples  should  be  adequate  to  il¬ 
lustrate  the  types  of  variation  which  might  be  en¬ 
countered.  Most  of  the  examples  concern  develop¬ 
ment  or  procurement  of  support  items,  hence  the 
deputy  program  manager  for  logistics  should  have  a 
keen  interest  in  them.  For  example, 

—  The  Army  frequently  buys  reprocurement  data 
with  development  funds,  whereas  the  Air  Force 
normally  buys  reprocurement  data  with  produc¬ 
tion  funds. 

—  The  development  and  procurement  of  technical 
orders  and  technical  manuals  are  normally 
funded  entirely  with  procurement  funds  by  the 
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Navy,  but  separately  by  development  and  pro¬ 
curement  funds  by  the  Air  Force. 

—  In  the  Army,  the  development,  testing,  and  pro¬ 
curement  of  support  items  are  normally  accom¬ 
plished  concurrently  with  development,  testing, 
and  procurement  of  the  primary  system.  Another 
service  may  prefer  that  development,  testing,  and 
procurement  of  support  be  delayed  and  much  of 
the  initial  support  be  provided  by  contractors. 

—  In  the  Army  and  Navy,  all  funding  for  develop¬ 
ment  and  procurement  of  a  new  system  and  its 
support  requirements  is  provided  by  the  materiel 
developer,  the  Department  of  the  Army  Materiel 
Development  and  Readiness  Command  or  the 
Naval  Material  Command.  In  the  Air  Force,  fund¬ 
ing  responsibility  is  split  between  the  Air  Force 
Systems  Command,  the  materiel  developer,  and 
the  Air  Force  Logistics  Command,  which  funds 
procurement  of  most  system  support,  such  as  ini¬ 
tial  spares,  depot  facilities,  and  initial  contractor 
support. 

The  lesson  to  be  learned  from  these  illustrations  is 
to  list,  early  in  the  program,  all  items  to  be  developed 
and  procured  and  to  review  the  list  in  detail  with  the 
comptrollers  or  other  knowledgeable  financial  mana¬ 
gers  in  each  participating  service.  Every  effort  should 
be  made  to  ensure  that  variations  among  the  services 
in  funding  practices  for  each  item  are  well  under¬ 
stood  and  that  the  joint  program  funding  plan  re¬ 
flects  these  funding  differences. 

Relationships  Outside  the  Program  Offfice 

Joint  program  managers  learn  soon  after  assuming 
office  that  certain  individuals  outside  their  program 
offices  can  expedite  or  impede  their  progress  and 
that  good  working  relationships  with  such  individuals 
should  be  established  at  the  outset.  Among  these 
people  are  the  service  comptrollers,  at  both  head¬ 
quarters  and  systems  command  levels.  For  instance, 
it  is  often  the  comptroller  of  the  systems  command 
providing  support  to  the  program  office  (e.g. ,  Naval 
Sea  Systems  Command)  who  issues  the  budget  call 
and  the  call  for  the  annual  program  objective  memo¬ 
randum  (POM)  to  which  the  joint  program  manager 
must  provide  inputs. 

Most  program  managers  have  found  it  advisable  to 
have  frequent  contact  with  the  comptroller  and,  at  all 
times,  to  be  as  forthright  as  possible  in  their  relation¬ 
ship.  For  instance,  if  the  program  manager  foresees 
a  circumstance  arising  which  might  prevent  him  from 
obligating  funds  as  planned,  it  might  be  well  to  so  ad¬ 
vise  the  comptroller.  This  is  good  insurance,  for  at 
some  later  date  the  program  manager  may  have  a 
genuine  need  for  funds  which  he  does  not  have.  He  is 


much  more  likely  to  get  a  sympathetic  hearing  from 
the  comptroller  if  he  has  cooperated  in  the  past. 

Other  individuals  outside  the  program  office  who 
can  be  of  great  help  to  the  program  manager  are  the 
action  officers  on  the  service  headquarters  staffs  who 
monitor  acquisition  programs.  (The  titles  and  roles  of 
these  staff  coordinators  are  discussed  in  Chapter  5. 
“Program  Review.”)  In  matters  of  planning,  pro¬ 
gramming,  budgeting,  and  program  review,  the  staff 
action  officers  can  be  instrumental  in  ensuring  that 
the  program’s  interests  are  well  presented  and  that 
the  services’  internal  administrative  requirements  are 
met  in  a  timely  manner. 

Cost  Estimating 

There  is  very  little  unique  about  estimating  the 
costs  of  a  joint  program.  Both  the  cost  estimating  re¬ 
quirements  and  the  methodologies  available  for  satis¬ 
fying  the  requirements  are  the  same  as  those  for 
single-service  programs.  The  procedures  of  the  Ex¬ 
ecutive  Service  should  suffice,  except  for  estimating 
the  support  investment  and  operating  and  support 
portions  of  life  cycle  costs. 

The  services  operate  in  different  environments,  are 
organized  to  accomplish  different  missions,  and  sup¬ 
port  their  forces  differently.  The  implication  of  these 
differences  is  that  support  concepts  and  require¬ 
ments  for  logistic  resources  vary  from  service  to  serv¬ 
ice,  even  when  all  the  services  are  operating  the 
same  type  of  equipment.  Estimates  of  support  invest¬ 
ment  and  operating  and  support  costs  must  reflect 
those  variations.  For  example,  the  equations  used  to 
estimate  the  cost  of  spare  parts  for  an  avionics  equip¬ 
ment  on  an  Air  Force  tactical  fighter  might  include  a 
war  reserve  spares  kit  (WRSK)  to  permit  squadron 
level  support  of  the  system  during  the  first  30  days  of 
a  deployment,  however  the  equations  used  to  com¬ 
pute  the  cost  of  spare  parts  for  an  identical  equip¬ 
ment  on  a  Navy  fighter  might  include  requirements 
to  support  a  60-day,  aircraft  carrier  deployment.  The 
cost-estimating  technique  used  by  the  joint  program 
must  be  tailored  to  satisfy  both  requirements. 

A  useful  approach  to  identifying  fundamental  dif¬ 
ferences  between  the  support  requirements  of  one 
service  and  those  of  another  is  to  write  a  system  pro¬ 
gram  definition  statement  (SPDS).  This  statement 
outlines,  for  each  service,  the  basic  assumptions 
which  must  be  made,  implicitly  or  explicitly,  in  any 
estimate  of  support  investment  and  operating  and 
support  costs.  The  following  elements  should  be  in¬ 
cluded: 

—mission  profile 

—system  characteristics  (e.g.,  configuration  and  crew 
requirements) 
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—acquisition  program  (e.g.,  delivery  schedule  for 
deployed,  training,  pipeline,  and  attrition  systems) 
—deployment  concept  (e.g.,  basing  plan  and 
operating  schedule) 

—support  concept 

—logistic  goals  (e.g.,  reliability  and  maintainability) 
—logistics  funding  plan 

Researching  and  developing  the  SPDS  provides 
valuable  insight  into  how  each  of  the  services  plans 
to  use  and  support  the  new  system.  Once  completed, 
the  SPDS  provides  a  sound  basis  for  the  cost  esti¬ 
mates.  The  next  step  is  to  select  the  cost  estimating 
models. 

Although  there  are  some  standard,  or  at  least  fre¬ 
quently  referenced,  life  cycle  cost  models  available  in 
the  DOD,  most  acquisition  programs  either  develop 
their  own  or  adapt  existing  models  to  their  needs. 
Frequently,  more  than  one  model  is  needed  to  make 
a  good  assessment  of  program  costs.  The  best  source 
of  information  about  models  and  the  peculiar  anal¬ 
ysis  requirements  associated  with  a  type  of  equip¬ 
ment  is  the  integrated  logistic  support  organization 
within  the  service’s  systems  or  commodity  command. 
For  example,  information  about  estimating  the  costs 
of  ground  electronics  equipment,  assistance  may  be 
found  in  the  Army  Communications  Electronics 
Command,  the  Naval  Electronic  Systems  Command, 
or  the  Air  Force  Acquisition  Logistics  Division,  Air 
Force  Logistics  Command. 

Program  analysts,  cost  analysts,  as  well  as  the  fi¬ 
nancial  manager,  must  understand  cost  data  or  en¬ 
sure  availability  of  experts  from  participating  services 
when  defending  programs  before  OSD,  OMB,  and 
Congress.  The  Army  has  recently  published  a  Hand¬ 
book  (DCP-P-58),  Understanding  Cost  Data, 
February  1981  indicating  that  staff  members  may 
find  the  handbook  useful  when  “about  to  testify  on 
the  hill.”  The  Joint  Program  Ofice  should  seek  out 
similar  information  from  participating  services  if  it  is 
not  covered  below.  Here  are  the  contents  of  DCA- 
P-58  (The  definition  of  terms  has  been  established  in 
DODI  5000.33  with  Army  implementation  by  AR 
11-18): 

Understanding  Cost  Data 

This  section  is  designed  to  provide  a  better  under¬ 
standing  of  key  cost  terms,  how  they  are  related,  and 
how  they  can  be  used  more  precisely.  It  also  provides 
reference  lists  of  unit  costs  for  selected  systems. 

Summary 

Figure  7-1— Materiel  Systems  Cost  Terms.  Eight 
definitions  from  AR-11-18,  The  Cost  Analysis  Pro¬ 


gram,  are  restated  in  layman’s  terms.  This  regulation 
implements  and  expands  upon  DODI  5000.33, 
Uniform  Budget/Cost  Terms  and  Definitions. 

Figure  7-2— Relationships  of  Key  Cost  Terms.  The 
same  eight  cost  terms  identified  in  Figure  1  are 
shown  in  their  relationship  to  each  other  and  to  the 
primary  phases  in  the  life  cycle  of  a  system.  Procure¬ 
ment  cost  and  its  components  should  be  studied 
carefully  as  this  is  the  area  that  is  most  misunder¬ 
stood. 

Figure  7-3— Relationship  Between  Life  Cycle 
Phase  and  Appropriations.  This  matrix  is  drawn  from 
cost  data  of  several  systems.  It  shows  that  costs  as¬ 
sociated  with  any  phase  of  a  system’s  life  cycle  can  be 
composed  of  multiple  appropriations. 

Figure  7-4— Use  of  Cost  Terms  in  Primary  Source 
Documents.  Primary  source  documents  are  not  con¬ 
sistent  in  their  reference  to  the  cost  terms  described 
herein. 

Figure  7-5— Specifying  Unit  Cost.  Unit  cost  data, 
or  cost  of  a  single  item,  is  particularly  troublesome 
because  of  the  many  ways  in  which  dollars  can  be  ex¬ 
pressed  and  quantity  can  be  measured.  Any  state¬ 
ment  of  unit  cost  must  indicate  which  qualifiers  are 
in  use  for  both  dollars  and  quantity. 

Figure  7-6— Procurement  Unit  Costs  for  Selected 
Acquisition  Report  (SAR)  Systems.  Costs  are  given  in 
both  constant  FY  82  dollars  and  in  current  year  dol¬ 
lars  as  contained  in  SARs.  In  all  cases  the  period 
used  to  derive  the  unit  cost  is  over  the  life  of  the  pro¬ 
gram. 

Figure  7-7— XM-1  Unit  Cost  Summary.  An  exam¬ 
ple  of  hardware  through  program  acquisition  costs 
for  an  actual  system.  Follows  the  format  of  the  unit 
cost  summary  contained  in  Appendix  C,  AR  11-18. 

In  addition,  the  DOD  Cost  Analysis  Improvement 
Group  and  each  of  the  services  has  published  policy 
or  guidance  on  life  cycle  cost  management.  The  fol¬ 
lowing  are  the  primary  references: 

—Office  of  the  Secretary  of  Defense,  Cost  Analysis 

Improvement  Group,  Aircraft  Operating  and  Sup¬ 
port  Cost  Development  Guide,  15  April  1980. 

Department  of  Army  Pamphlets 

No.  11-2  Research  and  Development  Cost  Guide 
for  Army  Materiel  Systems 

No.  11-3  Investment  Cost  Guide  for  Army 
Materiel  Systems 

No.  11-4  Operating  and  Support  Cost  guide  for 
Army  Materiel  Systems 

No.  11-5  Standards  for  Presentation  and 
Documentation  of  Life  Cycle  Cost 
Estimates  for  Army  Materiel  Systems 
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—Secretary  of  the  Navy  Instruction,  SECNAVINST 
4000.31,  Life  Cycle  Costing 

—Air  Force  Regulation,  AFR  800-11,  Life  Cycle 
Cost  Management 


Figure  7-1 

MATERIAL  SYSTEMS  COST  TERMS 


Explanation,  in  layman's  terms,  of  cost  definitions  contained  in  AR  11-18,  The  Cost  Analysis  Program. 
ALL  TERMS  EXCEPT  HARDWARE  COSTS  ARE  AUTHORIZED  BY  DODI  5000.33,  UNIFORM 
BUDGET/COST  TERMS  AND  DEFINITIONS. 

1.  HARDWARE  COST  Includes  only  production  costs  to  bring  a  major  end  items  out  of  a 
manufacturer's  plant. 

Used  in  the  Army  for  Trade-off  analysis,  Configuration  control, 

2.  FLYAWAY,  ROLLAWAY  COST  All  production  costs  to  enable  production  and  management  of  a 
major  end  item. 

Used  by  OSD  for  internal  management,  Design-To-Cost  (DTC) 

3.  WEAPON  (MATERIEL)  SYSTEM  COST  Flyaway  costs  plus  additional  major  end  item  costs  (new 
equipment  training;  operation,  maintenance,  and  training  manuals;  technical  and  managerial  data; 
and  peculiar  support  equipment). 

Used  in  Congressional  Data  Sheets  (P.L.  requirement). 

4.  PROCUREMENT  COSTS  Adds  initial  provisioning  of  spares  and  repair  parts  to  Weapon  System 
Cost. 

Used  in  Congressional  Data  Sheets,  President's  Budget  (may  be  in  separate  lines),  and  SARs. 

5.  DEVELOPMENT  COSTS  All  costs  of  research  and  development  from  the  time  the  program/system 
is  designated  by  title  as  a  Program  Element  or  major  project  in  a  Project  Element. 

Used  in  PPBS,  Congressional  Descriptive  Summaries  and  Data  Sheets,  and  as  part  of  Program 

Acquisition  Costs. 

6.  PROGRAM  ACQUISITION  COSTS  Includes  the  costs  of  research  and  development,  associated 
military  construction,  and  the  Procurement  Costs  thus  capturing  all  the  costs  necessary  to  place  a 
new  materiel  system  in  the  field 

Used  in  Congressional  Data  Sheets,  SARs  and  OSD  Cost  Analysis  Improvement  Group  (CAIG) 

deliberations. 

7.  OWNERSHIP  COSTS  All  costs  associated  with  operation  and  supporting  fielded  equipment 

Used  by  management  in  planning  and  programming,  trade-off  analyses 

8.  LIFE-CYCLE  COSTS  The  total  costs  to  the  Government  for  a  system  over  its  full  life  including  all  of 
the  above  and,  where  applicable,  disposal  costs. 


Used  by  management  in  Planning,  Cost  benefit  analyses,  Affordability  assessments. 
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Figure  7-2 

RELATIONSHIPS  OF  KEY  COST  TERMS 


Phases  in  the  Life  Cycle  of  a  System 


Costs  Associated  with  Life-Cycle  Phases 


Figure  7-3 

RELATIONSHIP  BETWEEN  LIFE-CYCLE 
PHASE  AND  APPROPRIATION 
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Figure  7-4 

USE  OF  COST  TERMS  IN  PRIMARY  SOURCE  DOCUMENTS 
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SPECIFYING  UNIT  COST 

•  UNIT  COST  =  DOLLARS  ■+■  QUANTITY 

•  BEFORE  DISCUSSING  UNIT  COSTS  PARTIES  MUST  AGEEE  ON 

••  TYPE  OF  DOLLARS 

••  TIME  PERIOD  OVER  WHICH  DOLLARS  AND  QUANTITY  ARE  MEASURED 

•  SEVER  AL  VAR  I ATIONS  APPEAR  IN  SOURCE  DOCUMENTS: 


TIME  PERIOD  OVER 
WHICH  MEASURED 


SINGLE  YEAR 


OVER  LIFE 
OF  PROGRAM 


TYPE  OF  DOLLAR 

CURRENT 

YEAR  S 

CONSTANT 

F  Y — $ 

PI 

CONGRESSIONAL 
DATA  SHEETS 

CONGRESSIONAL 
DATA  SHEETS 

SAR 

SAR 

SINGLE  YEAR 


OVER  LIFE 
OF  PROGRAM 


XM-1  CASE  ILLUSTRATION 
PROCUREMENT  UNIT  COST 

CURRENT 

CONSTANT 

YEAR  $ 

FY— $ 

CDS 

FY  82 

CDS: 

$2,367 

N/A 

SAR: 

$2,549 

(FY  82 

CONSTANT) 

BUSS: 

$1,906 
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Figure  7-6 

PROCUREMENT  UNIT  COSTS  FOR  SELECTED 
ACQUISITION  REPORT  (SAR)  SYSTEMS  (AS  OF  31  DEC  80)' 
($  IN  MILLIONS,  QUANTITY  MEASURED  OVER 
LIFE  OF  SYSTEM) 


SAR 

SYSTEMS 

WEAPON  SYSTEM 

UNIT  COST 

PROCUREMENT 

UNIT  COST 

CONSTANT 

FY  82  $ 

CURRENT 
YEAR  $ 

CONSTANT 

FY  82  $ 

CURRENT 
YEAR  $ 

AAH 

6.585 

9.383 

7.145 

10.182 

BLACKHAWK 

4.130 

5.258 

4.328 

5.51 

CH-47  (A  TO  D  MOD) 

5.933 

8.668 

6.270 

9.16 

COPPERHEAD 

.020 

.025 

.020 

.025 

D1VAD  GUN  W/O  AMMO 

3.558 

5.741 

3.936 

6.353 

FVS  (VEH  ONLY) 

1.04 

1.558 

1.11 

1.654 

HELLFIRE  (MSL) 

.018 

.025 

.018 

.025 

MLRS (ROCKET) 

.0059 

.0083 

.0059 

.0083 

MLRS  (SPLL) 

1.667 

1.935 

1.912 

2.256 

M198 

.385 

.330 

.388 

.333 

PATRIOT  (MSL) 

.433 

.543 

.433 

.543 

PATRIOT  (FIRE  UNIT) 

43.716 

54.733 

48.034 

60.139 

PERSHING  II  (MSL) 

1.701 

2.130 

1.701 

2.130 

Pll  BATTERY  SET  (TOTAL) 

N/A 

N/A 

21.5 

26.9 

ROLAND  (MSL) 

.258 

.230 

.258 

.230 

ROLAND (FU  +  VEH) 

19.73 

17.583 

19.73 

17.583 

SOTAS  (DIV  SET) 

71.7 

109.0 

84.145 

127.9 

STINGER  (BASIC  MSL) 

.042 

.051 

.042 

.051 

TACFIRE 

3.875 

2.9 

4.135 

3.095 

XM-1 

1.831 

2.448 

1.906 

2.540 

Figure  7-7 

XM-1  CASE  ILLUSTRATION' 


UNIT  COST  TERM2 

CONSTANT3 

FY  72  $(K) 

CURRENT 

FY  $( K ) 

(1)  HARDWARE  UNIT  COST 

642.6 

2235.9 

(2)  ROLLAWAY  UNIT  COST 

676.1 

2312.9 

(3)  WEAPON  SYSTEM  UNIT  COST 

720.0 

2448.1 

(4)  PROCUREMENT  UNIT  COST 

752.9 

2548.7 

(5)  PROGRAM  ACQUISITION  UNIT  COST 

833.9 

2680.7 

NOTE:  1.  EXTRACTED  FROM  UNIT  COST  SUMMARY  PREPARED  IN  CONJUNCTION  WITH  SAR, 
31  DEC  80. 

2.  UNIT  COSTS  ARE  MEASURED  OVER  THE  TOTAL  PROGRAM  LIFE. 

3.  FY  72  IS  BASE  YEAR  FOR  XM-1. 
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CHAPTER  8 
Engineering, 
Production,  and 
Software 
Management 


More  information  is  available  on  the  subject  of 
engineering  management  than  on  any  other  aspect  of 
joint  acquisition.  The  range  extends  from  DOD-wide 
authoritative  documents— the  Defense  Acquisition 
Regulation  (e.g.,  DAR  1-324,  “Warranties”),  Military 
Standards  (e.g.,  MILSTD  490,  “Specification  Prac¬ 
tices”),  DOD  and  service  directives,  instructions, 
regulations,  orders,  pamphlets,  etc.— to  purely  infor¬ 
mational  sources,  such  as  articles  in  professional 
journals.  References  to  the  functional  areas  covered 
vary  from  the  formal,  e.g.,  “life  cycle  cost  factors,”  to 
the  idiomatic  “ilities”:  reliability,  availability,  main¬ 
tainability,  transportability,  supportability,  etc. 

The  joint  program  manager  will  not  personally  be 
able  to  “manage”  these  engineering  functional  areas, 
in  spite  of  the  fact  that  they  comprise  the  substance 
of  the  program.  Depending  on  the  program  manage¬ 
ment  office  structure,  self-contained  vs.  matrix  (see 
Chapter  6,  “Organization  and  Staffing”),  the  joint 
program  manager  must  determine  how  much  effort 
he  personally  can  expend  in  keeping  his  engineering 
functional  teams  directed  toward  the  specific  pro¬ 
gram  goals. 

Consistent  Approach  to 
Engineering  Management 

There  are  some  factors  in  engineering  manage¬ 
ment  that  are  clearly  in  the  joint  program  manager’s 
favor.  The  operational  requirement,  which  drives  en¬ 
gineering,  should  have  been  well  established  during 
the  joint  service  interplay.  The  acquisition  strategy, 
which  also  provides  direction  to  engineering 
management,  i.e.,  P3I  (Preplanned  Product  Im¬ 
provement),  must  be  integrated  into  the  engineering 
planning.  Also,  a  great  deal  of  inter-service  and  DOD 
cooperation  has  been  expended  toward  the  develop¬ 
ment  of  common  standards  in  engineering  disci¬ 
plines.  Regardless  of  his  service  attachment,  the 
director  or  a  member  of  an  engineering  division  will 
be  familiar  with  the  core  requirement  for  that  func¬ 
tion.  For  example,  reliability  programs  in  all  the  serv¬ 
ices  have  their  roots  in  the  DOD-wide  MILSTD  785. 
Similarly,  all  maintainability  programs  are  based 


upon  MILSTD  470. 

“The  tailoring  of  standards,  specifications,  and 
data  requirements  is  another  factor  that  will  aid  the 
program  manager.  Current  OSD  and  service  direc¬ 
tion  requires  the  modification  of  these  documents  to 
meet  system  development  and  management  needs.1 
OSD  established  the  practice  of  selective  application 
of  standards  and  specifications  to  enhance  cost- 
effective  acquisition  and  life  cycle  ownership  of 
systems  in  1977.  The  directive  to  reduce  the  blanket 
application  of  all  available  contract  clauses  was  pro¬ 
mulgated  upon  the  findings  of  the  Defense  Science 
Board  Task  Force  on  Specifications  and  Standards 
that  misinterpretation,  overdemonstration  of  com¬ 
pliance  and  rigid  enforcement  of  specifications  and 
standards  by  Government  authorities  and  by  contrac¬ 
tors  was  the  primary  contributor  to  late  and  more- 
costly-than-estimated  systems.2  The  joint  program 
manager  should  be  especially  alert  to  the  specifica¬ 
tion  tiering  effect,  in  which  literally  hundreds  of 
detailed  specifications  are  called  out  automatically  by 
the  citing  of  a  general  specification  or  standard. 
Blanket  application  and  specification  tiering  is  now 
being  controlled  by  requiring  the  justification  of  the 
documents  cited  in  the  solicitation,  and  by  limiting 
the  application  of  the  documents  to  only  those  cited 
to  the  extent  specified.”3 

The  deft  management  of  the  “ilities”  is  also 
facilitated  by  the  knowledge  that  many  of  the 
engineering  management  practices  have  their  vogue 
periods,  champions  and  detractors.  Value  engineer¬ 
ing,  tailoring,  “should  cost,”  reliability,  and  main¬ 
tainability  warranties  all  have  flowered.  Those  which 
lose  their  attraction,  either  because  of  a  loss  of  their 
effectiveness  or  their  promoters,  generally  do  not  dis¬ 
appear,  but  linger.  Transportability  is  an  “ility” 
which  is  not  subject  to  vogue  trends;  equipment  or 
structures  which  are  to  be  transported  must  be  trans¬ 
portable.  The  joint  program  manager  should  seek 
the  advice  of  executive  and  participating  service  ex¬ 
perts  to  learn  which  are  effective  and  accepted  tools. 
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Production  Management 

Production  management  goals  are  to:  (1)  accom¬ 
plish  production  planning  during  the  development 
cycle  in  acquisition  programs,  (2)  document  and 
review  pertinent  production  criteria  before  the  deci¬ 
sion  to  produce,  and  (3)  monitor  the  production  pro¬ 
gram  after  that  decision  is  made. 

Production  management  must  ensure  that  designs 
are  capable  of  effective  and  economical  production 
under  quantity  manufacturing  conditions.  Produc¬ 
tion  risks  must  be  detected  and  resolved  to  minimize 
the  financial  commitments  associated  with  the  deci¬ 
sion  to  enter  production.  Production  management 
involvement  begins  with  determining  leadtimes, 
schedule  requirements,  and  production  reporting  re¬ 
quirements,  analyzing  contractor  responses,  and 
providing  an  active  production  interface  with  other 
functional  specialists.  Industrial  processes,  techni¬ 
ques,  and  controls  involved  in  manufacturing  and 
delivery  should  be  surveyed  continually  to  determine 
whether  the  program  plan  and  milestones  are  being 
achieved,  to  anticipate  problems,  and  to  take  action 
to  prevent  or  minimize  adverse  impact. 

Production  management  seeks  to  ensure  that  (1)  pro¬ 
duction  feasibility  is  properly  assessed;  (2)  manage¬ 
ment  possesses  potential  schedule  impacts;  (3)  plans 
for  quantity  production  effect  the  most  economical 
and  efficient  use  of  manpower,  materials,  machines, 
facilities,  and  methods.  An  active  role  is  taken  in 
Preliminary  Design  Reviews  (PDRs),  Critical  Design 
Reviews  (CDRs),  and  other  program  reviews  during 
the  design  and  development  phases  of  the  program. 

Production  Readiness  Reviews  (PRRs)  should  be 
accomplished  and  documented  before  the  produc¬ 
tion  decision  to  ensure  that  a  practical,  transport¬ 
able,  and  producible  engineering  design  has  been  ac¬ 
complished,  all  important  engineering  and  manufac¬ 
turing  process  problems  have  been  resolved,  the  con¬ 
tractor  has  adequately  planned  for  production  and 
has  the  manufacturing  and  technical  capability  to 
produce  the  given  system. 

The  program  office  should  implement  liaison  and 
operating  procedures  to  ensure  effective  Government 
involvement  with  the  contractor  sufficient  to 
establish  a  strong  and  mutually  knowledgeable  rela¬ 
tionship  between  the  procuring  activity,  contract  ad¬ 
ministration  activity  and  the  contractor.  Surveillance 
of  the  contractor  production  operations  should  be 
accomplished  in  sufficient  depth  to  fully  protect  the 
interests  of  the  Government  in  accordance  with  Sec¬ 
tion  25  of  the  Defense  Acquisition  Regulation  (DAR- 
ASPR). 

RFPs  and  SOWs  for  the  full-scale  development 


phase  and  production  phase  contracts  incorporate 
requirements  for  the  contractual  preparation  of 
manufacturing  and  production  plans,  including  the 
make  or  buy  plan,  and  establish  the  basis  for  pro¬ 
gram  office/CAO/contractor  involvement. 

When  a  full-scale  development  phase  has  been  ac¬ 
complished  by  the  contractor  selected  for  the  pro¬ 
duction  effort,  make  or  buy  planning  may  have  been 
performed  and  may  require  only  an  updating  for  pro¬ 
duction.  If  not,  the  make  or  buy  plan  may  be  secured 
as  part  of  the  production  plan.  It  must  be  available 
before  negotiation  and  continuously  updated  for 
review  and  approval  to  ensure  that  the  contractor 
does  not  create  in-house  capability  at  the  expense  of 
the  Government  when  adequate  capability  exists 
from  a  qualified  competitive  source. 

The  SOW,  the  approved  Manufacturing  and  Pro¬ 
duction  Plan,  and  the  contract’s  requirements  for 
manufacturing  and  production  reporting,  establish 
the  basis  for  monitorship  by  the  program  office  and 
for  the  surveillance  by  contract  administration. 

Software  Management 

Control  of  the  development  of  software  and  its 
documentation  is  a  requirement  which  has  become 
more  significant  and  demanding  with  the  increasing 
degree  of  incorporation  of  computer  technology  into 
military  systems.  The  voluminous  and  esoteric  nature 
of  computer  software  makes  its  management  ex¬ 
tremely  challenging.  The  Joint  Program  Manager 
(JPM)  is  tasked  to  determine  and  direct  the  steps 
necessary  to  keep  the  software  development  from 
becoming  an  impediment  to  project  completion.  Ad¬ 
ditionally,  the  JPM  will  ensure  that  the  potential  for 
interservicing  of  software  is  reviewed  and  that  all 
software  support  options  are  fully  analyzed.  Of  all  the 
tasks  performed  by  the  JPM,  one  of  the  most  impor¬ 
tant  entails  working  closely  with  using  and  devel¬ 
oping  activities  to  ensure  that  the  resulting  system 
fulfills  its  designated  requirements.  This  task 
becomes  more  and  more  challenging  as  the  system 
deployment  date  approaches.  The  JPM  also  must 
contend  with  the  fact  that  each  of  the  armed  services 
has  different  software  configuration  management 
policies  which  will  complicate  the  management  of 
any  Joint  Service  Project.  Regardless  of  the  policy 
differences  in  software  configuration  management, 
the  JPM  must  maintain  configuration  management 
control  of  the  software  as  long  as  the  engineering 
responsibility  remains  with  the  JPM.  The  JPM  must 
also  consider  future  requirements  to  ensure  suffi¬ 
cient  memory  core  will  be  available  to  preclude  costly 
modifications. 
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One  of  the  goals  of  the  Joint  Logistics  Com¬ 
manders  is  standardization  of  software  management 
policy  as  it  applies  to  Defense  systems  containing  tac¬ 
tical  embedded  computers.  At  the  present  time  ef¬ 
forts  are  underway  to  establish  a  joint  service  policy 
document,  to  establish  joint  service  software  develop¬ 
ment  standards,  to  promulgate  a  tri-service  software 
quality  assurance  policy/development  standard,  and 
to  develop  a  unified  group  of  Data  Item  Descriptions 
(DIDs). 

Configuration  Control 

One  facet  of  engineering  management  that  will  re¬ 
quire  increasing  attention  by  the  joint  program  man¬ 
ager  is  the  need  to  control  engineering  changes.  Of 
the  many  factors  which  contribute  to  the  pressure  for 
engineering  changes  in  system  design,  three  are  sig¬ 
nificant  and,  unfortunately,  inter-related.  First,  vali¬ 
dated  changes  to  system  requirements  by  the  spon¬ 
soring  organizations  inevitably  lead  to  changes  in  the 
system  design.  The  joint  program  manager  should  be 
especially  alert  to  these  and  must  require  that  spon¬ 
sors  recognize  that  incrementally  changed  re¬ 
quirements  can  bring  about  a  virtually  new  program. 
Second,  pressure  for  change  comes  from  the  tech¬ 
nology  community— government  and  contractor  lab¬ 
oratories— who  find  a  better  way  to  accomplish  the 
original  requirement  after  acceptance  of  a  pre¬ 
liminary  design.  Developmental  tests  will,  of  course, 
bring  to  light  those  system  specifics  which  require 
change  to  allow  the  system  to  work.  The  third,  and 
most  insidious,  source  of  pressure  to  change  a  design 
is  not  really  separate  from  the  first  two  at  all.  It  is  the 
seemingly  geometric  rate  of  technological  advance¬ 
ment  in  today’s  world  which  would  require  a  system 
to  be  conceived,  designed,  tested,  produced,  and 
fielded  in  a  year  to  prevent  its  obsolesence  before 
deployment.  It  is  this  last  pressure  which  will  cause  a 
program  never  to  reach  fruition  if  the  program 
manager  cannot  resist  incorporating  every  “im¬ 
proving”  change.  He  must  establish  a  psychology 
against  change. 

The  Standard  Integrated  Support  Management 
System  (SISMS)  discussed  in  Chapter  9,  “Logistics,” 
provides  configuration  management  guidelines  and 
provides  a  bibliography  of  directives  and  standards 
which  specify  the  details  of  a  configuration  manage¬ 
ment  plan  and  an  outline  for  a  configuration  manage¬ 
ment  joint  operating  procedure.  The  service  con¬ 
figuration  management  regulations,  as  well  as 
SISMS,  prescribe,  in  varying  formats,  the  means  to 
systematically  identify,  evaluate,  coordinate,  ap¬ 
prove,  and  implement,  or  disapprove  changes  in  a 
configuration.  The  plan  must  treat  information  such 
as: 


—  Proposed  level  of  authority  and  indenture  for 
change  control  at  the  start  of  engineering  devel¬ 
opment  and  the  anticipated  expansion  of  this 
control  as  the  design  and  testing  progresses 

—  Requirements  for  contractors’  internal  configura¬ 
tion  management  systems 

—  Change  analysis  and  approval  procedures  • 

—  Configuration  accounting  data  elements  and 
functions  on  which  data  will  be  collected 

—  Plans  and  timing  for  the  audit  of  configuration 

—  Timing  and  criteria  for  the  application  of  the  pro¬ 
duct  configuration  baseline  and  rationale 
supporting  the  timing 

—  Plans  to  handle  production  change  testing 

—  Ensure  interface  with  existing  systems 

The  building  blocks  are  well  documented  and  pre¬ 
sented.  It  remains  only  for  the  joint  program  man¬ 
ager  to  infuse  a  sense  of  priority  and  management  in¬ 
terest  into  the  plan  by  his  devotion  of  some  time  and 
attention  to  it. 

The  joint  program  manager  may  get  more  pressure 
for  changes  in  system  design  than  will  a  single¬ 
service  program  manager  because  of  requirements 
changes  from  the  participating  services.  Well-defined 
requirements  and  the  problems  stemming  from 
failure  to  achieve  them  prior  to  engineering  develop¬ 
ment  are  addressed  in  Chapter  3.  Changing  require¬ 
ments  cannot  be  handled  by  configuration  control 
board  procedures,  but  the  sponsors’  knowledge  of 
the  program  manager’s  resistance  to  unnecessary 
change  may  prevent  incremental  requirements  up¬ 
grading  from  gathering  momentum. 

It  is  axiomatic  in  the  field  of  program  management 
that  risk  and  commitment  have  an  inverse  relation¬ 
ship  throughout  the  acquisition  process.  The  pro¬ 
gram  manager  may  wish  to  tie  the  parameter  “resis¬ 
tance  to  change”  to  that  of  commitment  in  his  pro¬ 
gram  management  plan  so  that  at  each  succeeding 
development  milestone,  as  risk  is  expected  to 
decrease,  resistance  to  change,  as  well  as  commit¬ 
ment,  is  expected  to  increase.  The  recognition  of 
such  a  management  policy  by  sponsors,  developers, 
and  contractors  will  preclude  their  interpretation  of 
the  joint  program  manager’s  early  seeking  of  innova¬ 
tion  as  his  continuing  acceptance  of  change. 

Footnotes 

1.  Department  of  Defense  Directive  4120.21,  “Specifications  and 
Standards  Application,”  3  November  1980. 

2.  Report  of  the  Task  Force  on  Specifications  and  Standards.  Office 
of  the  Director  of  Defense  Research  and  Engineering,  Defense  Science 
Board,  1977. 

3.  Major  R.  J.  Pratt,  USAF,  “Partitioning  of  Military  Standards  and 
Specifications,”  DSMC  Study  Project  Report,  PMC  77-2  (DDC 
Reference  AD  A050529). 
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Chapter  9 
Logistics 


Assignment  of  A  Deputy  Program 
Manager  for  Logistics 

No  other  aspect  of  joint  program  management  will 
confront  the  manager  with  as  many  inter-service  dif¬ 
ferences  as  logistics.  Even  in  the  event  that  the  pro¬ 
gram  successfully  develops  a  prime  system  that  can 
meet  the  needs  of  all  participating  services  with  a 
single  configuration,  the  services’  support  require¬ 
ments  are  likely  to  be  different,  as  will  procedures  for 
achieving  effective  support.  The  deputy  program 
manager  for  logistics  must  orchestrate  these  various 
and  often  conflicting  policies  into  a  unified  and  cost- 
effective  logistics  program. 

To  be  effective,  the  deputy  program  manager  for 
logistics  should  be  the  same  grade  and  have  the  same 
authority  as  the  other  deputy  program  managers.  He 
should  be  delegated  program  management  responsi¬ 
bility  for  developing,  procuring,  and  deploying  the 
support  systems.  This  responsibility  must  include 
participating  in  design  reviews  and  advising  the  joint 
program  manager  of  the  support  implications  of  al¬ 
ternative  system  designs,  as  well  as  planning  the  inte¬ 
grated  logistic  support. 

The  deputy  program  manager  for  logistics  should 
be  provided  by  the  service  expected  to  bear  the 
greatest  burden  of  supporting  fielded  systems.  For 
most  programs  that  will  be  the  executive  service. 
However,  from  time  to  time,  one  service  will  be  desig¬ 
nated  the  executive  service  because  of  its  technical 
abilities  in  a  field  rather  than  its  dominant  share  of 
production.  In  such  programs,  the  participating  serv¬ 
ice  which  has  the  acquisition  responsibility  should 
provide  the  deputy  program  manager  for  logistics. 

The  deputy  program  manager  for  logistics  may  be 
either  a  civilian  or  military  officer  and  is  normally  as¬ 
signed  by  one  of  the  Army  Readiness  Commands,  the 
Navy  Systems  Commands  or  the  Air  Force  Logistics 
Command.  Ideally,  he  should  be  a  graduate  of  the 
Program  Management  Course  conducted  by  the 
Defense  Systems  Management  College  at  Fort 
Belvoir,  and  he  should  have  experience  at  several 
levels  of  logistics  management. 

Operating  Concepts 

The  starting  point  for  logistics  planning  is  an 
understanding  of  how  the  equipment  will  be  used: 


the  mission,  the  operating  environment,  the  tactical 
deployment,  and  the  forces  that  will  use  and  support 
it.  It  is  essential  that  the  operating  concept  be 
prepared  for  each  alternative  by  Milestone  I  and 
finalized  by  Milestone  II.  The  operating  concept 
should  be  clearly  understood  by  the  joint  program 
management  team. 

Logistics  planning  must  begin  at  the  initial  pro¬ 
gram  milestone,  i.e.,  program  initiation.  It  is  at  this 
point  that  the  deputy  program  manager  for  logistics 
will  review  the  mission  element  need  statements 
(JMSNS)  and  establish  the  baseline  equipment  opera¬ 
tion  and  logistic  environment.  All  of  the  services 
should  support  the  deputy  program  manager  in  for¬ 
mulating  an  initial  logistics  planning  document,  such 
as  the  Joint  Intergrated  Logistic  Support  Plan 
(JILSP).  Appendix  D  describes  the  recommended 
content  and  format  of  a  JILSP.  Given  identical  equip¬ 
ments,  the  four  services  will  employ  them  differently, 
thereby  generating  different  logistics  requirements. 
In  fact,  their  different  operating  concepts  are  certain 
to  influence  the  equipment  and  support  system 
design  significantly.  The  JILSP  will  focus  manage¬ 
ment  attention  on  the  problems  that  different 
operating  concepts  may  create  in  terms  of  equipment 
design  and  support  system  alternatives.  The  JILSP 
will  also  act  as  a  cohesive  agent,  forcing  the  services 
to  establish  and  integrate  their  logistics  plans  early. 
The  integrated  support  plan  (ISP)  prepared  by  the 
contractor  should  complement  the  JILSP  and  reflect 
the  contractors  approach  to  complying  with  the  logis¬ 
tics  requirements  established  for  the  joint  program. 

In  all  the  services,  the  operating  commands  deter¬ 
mine  how  a  system  is  used.  In  the  Army,  the  Training 
and  Doctrine  Command  (TRADOC)  normally  repre¬ 
sents  the  eventual  user.  In  the  Navy,  the  mission 
sponsor  (e.g.,  the  Deputy  Chief  of  Naval  Operations 
for  Air  Warfare)  usually  prepares  the  plan  for  use  and 
coordinates  it  with  the  Fleets.  In  the  Air  Force,  the 
using  command  (e.g.,  Tactical  Air  Command)  partici¬ 
pates  directly  in  the  acquisition  program,  influenc¬ 
ing,  among  other  things,  how  the  new  system  will  be 
employed. 

If  the  user  (or  his  representative  in  the  acquisition 
process)  does  not  specify  an  operating  concept  the 
program  manager  must  take  the  initiative,  force  the 
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issue  and,  in  practice,  set  up  some  strawmen.  As  the 
program  progresses  through  the  acquisition  process 
and  the  equipment  design  and  capabilities  become 
better  defined,  firm  operating  and  maintenance  con¬ 
cepts  will  evolve,  but  this  evolution  should  not  inhibit 
an  early  start  toward  documenting  preliminary  con¬ 
cepts.  If  these  concepts  are  not  defined  early,  the  lo¬ 
gistics  planning  baseline  will  not  be  properly  estab¬ 
lished,  and  program  schedule  and  cost  will  be 
adversely  affected. 

Support  Concepts 

Because  missions,  operating  concepts,  and 
operating  environments  differ  from  service  to  serv¬ 
ice,  so  also  do  standard  practices,  procedures,  and 
doctrines  for  providing  logistic  support.  There  are 
differences  in  practically  every  aspect  of  sup¬ 
port— the  organizational  structures,  type  of  support 
available  at  each  level,  occupational  skills,  training, 
facilities,  test  equipment,  and  support  environment. 
The  differences,  though  not  so  great  as  to  preclude 
effective  support  of  virtually  any  equipment  by  any 
service,  may  be  significant  enough  to  influence  dra¬ 
matically  the  preferred  equipment  design  (especially 
maintenance  characteristics),  the  range  of  feasible 
support  concepts,  and  the  support  resource  re¬ 
quirements  of  each  service. 

Consider  the  services’  standard  maintenance  struc¬ 
tures.  The  Army,  except  for  aircraft,  usually  dis¬ 
tinguishes  among  four  levels  of  maintenance:1  orga¬ 
nizational,  direct  support,  general  support,  and 
depot.  The  Navy  and  Air  Force  recognize  three 
levels,  as  does  the  Army  for  aircraft  maintenance:  or¬ 
ganizational,  intermediate,  and  depot.  The  Marine 
Corps  usually  follows  Army  practices  for  ground 
equipment  and  Navy  practices  for  aircraft. 

To  the  uninitiated,  it  might  appear  that  Army 
direct  and  general  support  are  comparable  to  Navy 
and  Air  Force  intermediate  maintenance,  but  that  is 
not  the  case.  Many  maintenance  tasks  done  at  the 
direct  support  level  in  the  Army  would  be  done  at  the 
organizational  level  in  the  Navy  or  Air  Force.  Many 
of  the  general  support  tasks  would  be  done  at  the 
Navy  or  Air  Force  depot. 

Nor  is  it  true  that  the  intermediate  level  in  the 
Navy  always  matches  that  in  the  Air  Force.  Ships,  for 
example,  must  be  largely  self-sufficient;  tasks  which 
would  be  intermediate  level  on  an  Air  Force  System 
might  be  considered  organizational  level  on  a  ship 

Footnotes 

1.  The  Army  actually  identifies  five  echelons  of  maintenance,  the  first 
two  of  which  (user  and  unit  maintenance)  are  both  considered  organiza¬ 
tional  level. 


system.  Even  for  aircraft  and  aircraft  systems,  where 
the  similarities  among  the  services’  maintenance 
structures  are  most  apparent,  there  are  major  differ¬ 
ences  in  the  environments,  facilities,  test  equipment, 
and  maintenance  skills  available  at  each  level.  To 
begin  to  appreciate  the  differences,  one  need  only 
imagine  the  maintenance  operations  on  a  pitching, 
rolling  deck  of  a  ship  or  a  hastily  prepared  jungle 
base  compared  to  those  on  an  established  air  field. 

There  are  frequently  also  differences  among  the 
services  in  the  proximity  of  support  organizations  to 
operating  forces.  Because  of  those  differences,  a  sup¬ 
port  concept  which  would  provide  one  service  with 
acceptable  maintenance  turn-around  times  may  be 
unable  to  support  the  desired  level  of  operational 
readiness  in  another  service. 

To  do  his  job  well,  the  deputy  program  manager 
for  logistics  must  understand  how  each  of  the  serv¬ 
ices  normally  supports  the  type  of  equipment  being 
acquired  by  the  joint  program.  He  has  to  educate 
himself.  His  best  source  of  information  in  the  Army  is 
the  TRADOC  centers  and  schools;  for  example,  the 
Combined  Arms  Center  and  School,  Fort  Leaven¬ 
worth,  Kansas.  In  the  Navy,  the  initial  contact  should 
be  the  appropriate  systems  command,  but  an  effort 
should  be  made  also  to  visit  one  of  the  fleets.  In  the 
Air  Force,  visits  to  the  Air  Force  Logistics  Command 
and  a  using  command,  such  as  the  Tactical  Air  Com¬ 
mand,  Langley  AFB,  should  provide  the  necessary 
background.  In  the  Marine  Corps,  a  visit  should  he 
made  to  the  Marine  Corps  Development  and  Educa¬ 
tion  Center  at  Quantico,  Virginia. 

In  short,  the  deputy  program  manager  for  logistics 
should  get  out  of  his  office  and  see  how  the  other 
services  really  support  their  forces.  He  will  then  have 
an  appreciation  for  the  differences  among  the  serv¬ 
ices  and  a  sound  basis  for  developing  a  support 
system  (or  support  systems)  that  will  be  effective, 
economical  and  implementable  in  each  service. 

Milestone  Planning 

The  single  most  important  task  facing  the  logistics 
manager  is  milestone  planning  (scheduling).  A  good 
milestone  program  will  save  countless  program  dol¬ 
lars  and  man-hours.  The  three  major  benefits  of  a 
well  designed  milestone  system  are: 

— Total  program  overview  and  direction 
—A  planning  guide  allowing  the  visability  required  in 
monitoring  the  various  logistics  contract  data  items 
—Evaluation  and  impact  of  schedule  changes. 

Milestone  planning  appears  to  be  the  most  ignored 
area  in  joint  programs.  Too  often,  management  sees 
a  milestone  system  as  a  hindrance  rather  than  the 
valuable  tool  it  is.  In  fact,  a  well  designed  milestone 
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system  will  allow  the  joint  program  manager  or  the 
deputy  program  manager  for  logistics  to  better  unify 
the  various  services’  requirements. 

There  are  many  ways  to  construct  a  milestone 
system.  The  most  basic  method  is  to  use  a  chart 
showing  due  dates  versus  completion  dates  for  the 
various  program  and  contract  elements.  Normally,  a 
chart  of  this  type  is  required  by  the  various  planning 
documents  such  as  the  JILSP.  One  step  beyond  this 
is  to  use  a  standard  program  evaluation  review  tech¬ 
nique  (PERT)  or  critical  path  method  (CPM)  system 
which  will  identify  problems  more  readily  than  a  sim¬ 
ple  chart.  The  deputy  program  manager  for  logistics 
cannot  know  all  of  the  ramifications  of  a  schedule 
change,  but  with  PERT  or  CPM,  at  least  some  of  the 
effects  of  a  change  can  be  known.  For  example, 
because  the  various  logistics  elements  are  inter¬ 
dependent,  a  schedule  change  in  the  technical 
manuals  area  will  affect  the  training  development, 
which  in  turn,  will  affect  testing,  etc.  Proper 
milestone  planning  will  mean  the  difference  between 
successful  logistics  management  and  failure. 

Milestone  planning  is  being  aided  by  a  variety  of 
automated  techniques,  many  of  them  available  com¬ 
mercially  and  some  used  routinely  by  contractors. 
One  of  the  more  innovative  systems  automates  the 
PERT.  Enhancements  to  the  automated  PERT 
include: 

—Automated  flagging  of  due  dates  and  pre-set 
suspenses 

—Automated  program  reconfiguring,  based  upon  dif¬ 
ferent  funding  or  planning  profiles 
—Automated  critical  path  reconfiguring  based  upon 
program  slippages 
—Current  status  reporting 

A  well-designed  milestone  planning  system  will 
form  the  core  of  the  logistics  effort  in  a  joint  pro¬ 
gram.  It  is  up  to  the  deputy  program  manager  for 
logistics  to  insure  that  such  a  system  not  only  is  im¬ 
plemented  and  maintained,  but  is  linked  directly  to 
the  milestone  planning  system  for  the  entire  joint 
program.  The  DPML  should  consider  that  auto¬ 
mated  systems  are  available  from  government  and 
commercial  sources  to  track  milestones  and  pinpoint 
problems  in  sufficient  time  to  initiate  required  action. 

Logistics  Support  Analysis 

The  logistics  support  analysis  (LSA)  program  was 
initiated  in  1973  as  a  joint  service  program.  The  de¬ 
tails  of  this  program  are  described  in  MIL-STD-1388. 
The  joint  program  manager  should  be  familiar  with 
this  MIL-STD.  The  objective  of  LSA  is  to  establish 
within  systems  engineering  a  process  that  will 
establish  logistics  as  a  design  parameter  and  mold 


the  individual  engineering  disciplines  into  a  cohesive 
unit.  There  are  two  key  elements  of  the  LSA  process 
that  contribute  to  the  integration  process.  The  first  is 
the  establishment,  within  the  design  activity,  of 
logistics  oriented  tasks  that  are  directly  relatable  to 
such  engineering  efforts  as  reliability,  maintainabil¬ 
ity,  and  standardization.  The  tasks  are  tailored  to  the 
specific  characteristics  of  the  engineering  program. 
The  second  key  element  in  the  LSA  process  is  the 
establishment  and  use  of  a  single  integrated  data 
base.  The  data  base  (see  Table  9-1)  will  be  the  sole 
source  of  design  related  logistics  data  pertaining  to 
the  engineering  effort.  The  data  system  provides  con¬ 
tractors  an  information  system  for  accomplishing  sys¬ 
tem  engineering  and  is  used  to  satisfy  government 
data  requirements.  The  LSA  deserves  the  highest 
visibility  within  the  joint  program  office.  The  advan¬ 
tages  of  such  a  common  data  base  for  individual 
logistics  functions  include  reduced  costs,  shorter 
procurement  leadtimes,  and  simplified  data  main¬ 
tenance  and  documentation.  In  a  joint  program, 
there  is  the  additional  advantage  of  spreading  the 
costs  of  developing  an  LSA  data  base  over  two  or 
more  services. 

Use  of  LSA  will  enable  the  deputy  program  mana¬ 
ger  for  logistics  to  consolidate  the  various  data  re¬ 
quirements  generated  by  the  services  into  a  single 
cohesive  contractual  record.  Although  it  may  first 
appear  that  consolidation  of  the  requirements  is 
nearly  impossible,  the  problem  can  be  overcome  by 
carefully  reviewing  each  service’s  requirements  and 
letting  the  service  with  the  greatest  requirements 
prepare  a  single  set  of  contract  requirements. 

Standard  Integrated  Support 
Management  System 

Development  of  the  standard  integrated  support 
management  system  (SISMS)  was  sponsored  by  the 
Joint  Logistics  Commanders  to  provide  a  uniform  ap¬ 
proach  to  planning  and  managing  the  logistics  sup¬ 
port  of  multi-service  programs.  It  has  been  imple¬ 
mented  by  regulation  or  instruction  in  all  the 
services: 

— U.S.  Army  Materiel  Development  and  Readiness 

Command,  DARCOM-R  700-97 

-Naval  Material  Command,  NAVMATINST  4000.38 

—Air  Force  Logistics  Command,  Air  Force  Systems 

Command,  AFLC/AFSCR  800-24 

—U.S.  Marine  Corps,  MCO  P4110.1A 

This  regulation  directs  that  SISMS  be  used  for  all 
multi-service  programs  and  that  it  be  considered  for 
use  on  all  other  programs.  The  Army  has  directed 
that  SISMS  be  applied  to  all  Army  acquisition  pro¬ 
grams,  multi-service  or  not. 
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Table  9-1 

LOGISTICS  SUPPORT  ELEMENTS  AS  SUPPORTED  BY  THE 
LOGISTICS  SUPPORT  DATA  FROM  LSA 


\  ELEMENTS  OF 
\LOGISTIC 

SUPPORT 

LOGISTIC  \ 
SUPPORT 

DATA  \ 

MAINTENANCE 

PLAN 

MANPOWER 

AND 

PERSONNEL 

INITIAL 

PROVISIONING 

AND  SUPPLY 

SUPPORT 

SUPPORT 

AND  TEST 

EQUIPMENT 

TRAINING 

AND  TRAINING 

DEVICES 

TECHNICAL 

DATA 

SOFTWARE 

SUPPORT 

TRANSPORTATION 

AND 

HANDLING 

FACILITIES 

HARDWARE 

IDENTIFICATION 

vS 

yS 

yS 

yS 

y/ 

y/ 

ys 

MAINTENANCE 

REQUIREMENTS 

vS 

yS 

yS 

yS 

yS 

yS 

yS 

yS 

yS 

MAINTENANCE 

LEVEL 

iS 

yS 

yS 

yS 

yS 

yS 

yS 

yS 

yS 

TASK  FREQUENCY 

ys 

yS 

yS 

v* 

yS 

yS 

yS 

yS 

TASK  TIME 

yS 

yS 

ys 

yS 

yS 

yS 

yS 

TASK  DESCRIPTION 

yS 

yS 

yS 

yS 

yS 

yS 

yS 

yS 

PARTS 

REQUIREMENTS 

yS 

ys 

S 

yS 

TOOL 

REQUIREMENTS 

yS 

ys 

yS 

yS 

yS 

yS 

SUPPORT  AND  TEST 

EQUIPMENT 

REQUIREMENTS 

yS 

yS 

yS 

yS 

yS 

yS 

yS 

yS 

yS 

FACILITY 

REQUIREMENTS 

yS 

yS 

yS 

PERSONNEL 

REQUIREMENTS 

yS 

yS 

yS 

yS 

yS 

yS 

yS 

ts  —  INDICATES  DATA  IS  USED  EITHER  DIRECTLY  OR  INDIRECTLY  IN  PRODUCTS 
ASSOCIATED  WITH  THE  ELEMENT  OF  LOGISTIC  SUPPORT. 
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The  intent  of  SISMS  is  to  define  joint  operating 
procedures  for  those  logistics  functions  not  already 
standardized  throughout  DOD.  The  abbreviated 
SISMS  table  of  contents  presented  in  Table  9-2  in¬ 
dicates  the  range  of  disciplines  covered.  A  typical 
SISMS  chapter  describes  policies,  references,  re¬ 
sponsibilities,  and  data  items. 

Deputy  program  managers  for  logistics  should  con¬ 
sider  SISMS  as  the  guide  for  developing  support 
management  systems  for  joint  programs.  SISMS 
should  be  followed  as  much  as  practicable,  early  in 
the  program.  Once  a  logistic  planning  approach  has 
been  started  it  is  difficult  to  change  because  much  of 
the  planning  and  data  are  being  procured  from  con¬ 
tractors.  The  SISMS  approach  is  more  likely  to  meet 
the  needs  of  a  joint  program  than  is  a  service- 
peculiar  approach.  But  there  are  many  aspects  of  lo¬ 
gistics  planning  for  joint  programs  that  are  addressed 
neither  by  SISMS  nor  by  service-peculiar  procedures. 
Let  us  address  them  as  lessons  learned. 

Lessons  Learned 

The  following  examples  and  advice  have  been  pro¬ 
vided  by  deputy  program  managers  who  are  or  have 
been  responsible  for  the  logistics  aspects  of  joint  pro¬ 


grams.  Not  every  joint  program  will  share  exactly  the 
same  experiences,  but  all  will  encounter  similar  situa¬ 
tions  brought  about  by  differences  among  the  logis¬ 
tics  requirements  and  practices  of  the  services. 

Inter-Service  Communication 

It  takes  longer  and  requires  more  work  to  ac¬ 
complish  logistics  planning  tasks  in  a  joint  program 
than  in  a  single-service  program.  It  was  noted  at  the 
beginning  of  this  chapter  that  the  logistician  must 
deal  with  more  inter-service  differences  than  anyone 
else  in  the  program  office.  Unlike  many  other  inter¬ 
service  issues,  logistics  issues  cannot  normally  be 
resolved  by  escalation  to  a  higher  decision  authority. 
Logistics  problems  normally  concern  nitty-gritty 
details  that  must  be  worked  out  among  functional 
specialists,  each  of  whom  may  not  only  have  narrow 
interests,  but  may  be  convinced  that  there  is  only  one 
way  to  perform  a  certain  task:  his  way.  Much  atten¬ 
tion  must  be  devoted  to  details  that  would  be  han¬ 
dled  routinely  in  a  single-service  program.  The  depu¬ 
ty  program  manager  for  logistics  must  ensure  that 
key  logistics  personnel  from  each  service  are  iden¬ 
tified  and  that  these  personnel  jointly  participate  in 
planning  and  establishing  the  logistics  program.  One 
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technique  for  accomplishing  this  is  to  establish  a 
hierarchy  of  program  review  teams.  These  teams  or 
committees  should  be  oriented  to  the  specific  level 
deemed  necessary.  A  hierarchy  may  be  constructed 
as  follows: 

Level  1:  Logistic  Status  Review  Team.  This  team 
may  comprise  the  program  manager,  the  deputy  pro¬ 
gram  managers,  the  highest  level  representatives 
from  the  participating  services,  as  well  as  any  support 
personnel  deemed  necessary.  Level  1  will  review 
overall  logistics  policy,  establish  major  milestones, 
and  resolve  problems  that  cannot  be  resolved  at 
lower  levels.  This  team  may  meet  only  three  or  four 
times  a  year,  or  when  deemed  necessary,  by  the  pro¬ 
gram  manager  upon  DPML’s  recommendation. 

Level  2:  Joint  ILS  Committee.  This  committee  or 
team  will  comprise  the  deputy  program  manager  for 
logistics  and  the  key  staff  and  management  person¬ 
nel  among  the  services  responsible  for  the  logistics 
effort.  This  committee  will  act  as  a  steering  group  for 
the  logistics  directives  from  the  Level  1  team,  the 
program  manager  or  deputy  program  manager  for  lo¬ 
gistics.  In  a  large  program,  the  Level  2  committee 
will  be  responsible  for  most  of  the  communication 
and  agreements  in  the  logistics  arena.  This  level  will 
meet  on  an  as-required  basis. 

Level  3:  Subcommittees  or  Working  Groups.  This 
level  will  comprise  the  functional  working  level.  This 
may  include  a  group  for  provisioning,  training,  LSA, 
etc.  The  actual  formatting,  data  requirements,  train¬ 
ing,  and  other  integrated  logistics  support  problems 
will  be  resolved  by  these  various  groups  or  teams. 
These  groups  will  be  established  by  the  Level  2  com¬ 
mittees  and  meet  on  an  as  required  basis.  Items  that 
cannot  be  resolved  at  this  level  will  be  presented  to 
the  Level  2  committee. 

Data 

Few  events  will  bring  out  the  parochial  interests  of 
the  services  more  quickly  or  more  dramatically  than 
the  data  call.  It  will  probably  be  the  first  inkling  the 
deputy  program  manager  for  logistics  will  get  of  the 
many  different  and  sometimes  conflicting  practices 
among  the  services.  Yet,  he  must  bear  in  mind  that 
there  frequently  are  legitimate  needs  for  service- 
peculiar  data.  For  example,  the  Air  force  frequently 
does  more  in-house  testing  and  analysis  than  the 
other  services  and  needs  data  to  support  those  ac¬ 
tivities.  There  also  arise  situations  in  which  dif¬ 
ferences  in  test  and  evaluation  criteria,  training  re¬ 
quirements,  or  support  concepts  lead  to  data  re¬ 
quirements  tailored  to  the  needs  of  each  service.  The 
challenges  will  be  first  to  ensure  that  all  re¬ 


quirements  are  known,  second  to  cull  the  essential 
from  the  nonessential,  third  to  develop  data  item 
descriptions  that  satisfy  all  requirements,  and  fourth 
to  verily  that  data  requirements  are  completely  and 
accurately  stated  in  contracts. 

Logisticians  who  have  experience  in  joint  pro¬ 
grams  point  out  that  the  data  item  descriptions  in 
SISMS  are  perhaps  the  most  useful  information  in 
the  document.  They  should  be  accepted  as  the  stand¬ 
ard  unless  the  reasons  for  modifying  them  are  com¬ 
pelling.  The  same  people  note  also  that  joint  pro¬ 
grams  often  are  created  by  merging  two  or  more 
single-service  programs.  One  of  the  early  tasks  of  the 
logistician  is  to  provide  inputs  to  modify  contracts  to 
satisfy  the  data  requirements  of  the  participating 
services.  If  SISMS  has  been  followed  from  the  begin¬ 
ning,  contract  modification  probably  will  involve  only 
additions.  If  SISMS  has  not  been  followed,  satisfying 
the  participating  services’  requirements  may  be  ex¬ 
pensive  or  even  infeasible. 

Supply  Support 

Provisioning  is  the  heart  of  supply  support  plan¬ 
ning  for  a  new  system.  All  services  follow  essentially 
the  same  well  defined  provisioning  policies.  A  list  of 
the  basic  references  is  in  SISMS,  Chapter  4.  The  pro¬ 
cedures  for  implementing  the  policies,  however,  vary 
from  service  to  service,  and  there  is  no  checklist  to 
guide  the  joint  program.  The  best  advice  to  the  depu¬ 
ty  program  manager  for  logistics  is  to  start  early,  in¬ 
clude  the  participating  services  in  planning  the  provi¬ 
sioning  procedures,  and  expect  provisioning  for  the 
joint  programs  to  take  much  longer  and  be  more 
confusing  than  provisioning  for  a  single-service  pro¬ 
gram.  The  following  issues  are  typical. 

Each  service  has  its  own  supply  system, 
governed  by  its  own  procedures,  and 
automated  through  its  own  computer 
systems.  When  an  item  managed  by  one 
service  is  requisitioned  by  another,  the  re¬ 
quisition  starts  in  the  originator’s 
automated  support  system,  is  withdrawn 
from  that  system  and  processed  manually, 
then  entered  into  the  managing  service’s 
automated  supply  system.  Not  only  is  the 
inter-service  requisitioning  process 
cumbersome,  but  there  are  more  than  the 
usual  opportunities  for  error.  The  most 
common  errors  are  incorrect  stock 
numbers,  failure  of  the  executive  service 
to  register  the  requisitioning  service  as  a 
user,  omission  of  the  funding  citation, 
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and  misplacement  or  mishandling  of  the 
requisition  in  the  manual  system.  In 
multi-service  provisioning  it  is  imperative 
that  a  monitoring  program  be  instituted 
for  the  cataloging/provisioning  phases  of 
the  program.  Without  monitoring  the 
system,  many  catalog  transactions  are  re¬ 
jected  and  not  controlled.  Actions  pro¬ 
cessed  through  the  cataloging  system  may 
subsequently  be  rejected  in  various  inter¬ 
face  systems.  One  goal  of  provisioning  is 
to  lay  the  groundwork  for  avoiding  such 
errors.  The  Defense  Logistics  Agency 
(DLA)  with  its  various  centers  will  be  the 
central  inventory  control  point  for  many 
items  that  are  used  across  service  lines.  A 
well  organized  joint  service  program  will 
have  a  single  service  doing  all  the  provi¬ 
sioning  for  a  particular  hardware  con¬ 
figuration.  This  will  eliminate  duplication 
of  effort  as  well  as  minimize  costs. 

The  source,  maintenance  and 
recoverability  (SMR)  coding  for  an  item 
may  be  different  for  each  service  par¬ 
ticipating  in  the  joint  program.  The  dif¬ 
ferences  may  be  the  result  of  different 
support  concepts,  or  they  may  result  from 
the  use  of  different  criteria  for  determin¬ 
ing  level  of  repair.  The  services  do  not  use 
the  same  model  for  determining  optimum 
repair  levels.  For  example,  the  Air  Force 
uses  repair  level  analysis  (RLA)  and  the 
Navy  uses  level  of  repair  analysis  (LORA). 
Though  the  models  are  similar,  they 
make  different  assumptions  about  such 
parameters  as  turn-around  times,  pipeline 
quantities,  and  repair  costs,  and  their 
results  are  frequently  different. 

The  services  should  consider  the  use  of  a 
single-level  of  repair  model  and  the  rele¬ 
vant  data  values  for  that  model  should  be 
obtained  well  in  advance  of  the  SMR 
coding  process.  Although  variations  in 
SMR  codes  among  participating  services 
are  possible,  they  should  be  avoided  if 
practicable.  Early  agreement  on  repair 
level  models  and  the  phase  of  the  pro¬ 
gram  when  logistics  support  capabilities 
will  be  acquired  will  reduce  the  need  for 
differing  SMR  codes.  Without  early  agree¬ 
ment,  there  may  not  be  enough  time  to 
negotiate  procedures  to  allow  the  services 
to  use  their  differing  maintenance  con¬ 
cepts  with  a  single  SMR  code. 


The  normal  timing  and  sequencing  of 
provisioning  events  vary  from  service  to 
service.  For  example,  prescreening  by  the 
Defense  Logistics  Services  Center  to 
determine  if  national  stock  numbers  have 
already  been  assigned  may  be  done  early 
in  the  provisioning  process  by  one  service 
and  late  by  another.  The  timing  of  provi¬ 
sioning  events  may  also  be  affected  by  dif¬ 
ferences  in  the  initial  support  dates  for 
each  of  the  services.  These  timing  and  se¬ 
quencing  issues  should  be  resolved  in  ini¬ 
tial  planning  for  the  provisioning. 

Support  Equipment 

If  support  concepts  for  a  system  differ  among  the 
services,  chances  are  that  the  requirements  for  sup¬ 
port  equipment  will  also.  Moreover,  the  services  may 
wish  to  use  their  own,  automated  general  purpose 
test  equipment,  rather  than  procure  new  equipment. 
This  will  create  a  requirement  for  service-peculiar 
software.  For  example,  the  Navy  has  versatile 
avionics  shop  test  (VAST)  aboard  its  aircraft  carriers, 
the  Army  is  using  the  AN/USM-410  and  the  Air 
Force  is  developing  modular  automatic  test  equip¬ 
ment  (MATE).  The  three  test  systems  are  not  com¬ 
patible;  each  requires  unique  software.  However, 
duplication  can  be  minimized  by  using  a  single  set  of 
data  for  the  software  programming  effort. 

Although  maintenance  concepts  of  the  services 
may  dictate  use  of  different  support  equipment, 
development  of  new  peculiar  SE  may  not  be  re¬ 
quired.  The  existing  DOD  inventory  should  always  be 
examined  for  a  previously  developed  item  which 
would  effectively  satisfy  requirements.  Agreement  on 
the  phase  of  the  program  in  which  automated  test 
equipment  software  will  be  procured,  as  well  as  on 
what  requirements  are  peculiar  should  be  reached 
very  early  in  the  program. 

Technical  Manuals 

The  services  have  fundamentally  different  re¬ 
quirements  for  technical  orders  (TOs)  or  technical 
manuals  (TMs).  These  differences  exist  because  the 
characteristics  of  the  intended  users  are  different. 
The  typical  Army  user  may  not  have  graduated  from 
high  school,  has  only  entry-level  military  training, 
and  has  little  experience.  To  meet  his  needs,  the 
Army  buys  skill  performance  aids:  simple,  very  ex¬ 
plicit  manuals  structured  in  prescribed  formats  and 
written  to  a  specific  level  of  comprehension.  They  are 
expensive.  The  typical  Air  Force  user  is  a  high  school 
graduate  who  is  expected  to  have  more  technical 
training  and  experience  than  his  Army  counterpart. 
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Consequently,  the  Air  Force  technical  orders  are 
akin  to  contractor’s  technical  documentation  and  de¬ 
pend  upon  the  technician’s  greater  knowledge  of  the 
equipment.  The  Navy  Functionally  Oriented  Main¬ 
tenance  Manuals  fall  midway  between  the  Army 
manuals  and  Air  Force  technical  orders,  both  in  sim¬ 
plicity  and  conciseness. 

The  deputy  program  manager  for  logistics  must 
critically  examine  the  characteristics  of  the  intended 
users  in  each  service  and  balance  the  needs  of  his 
program  for  technical  orders  or  manuals  with  the 
needs  of  the  other  services.  In  doing  so,  he  should 
ensure  that  the  documents  are  compatible  with  the 
support  concept  and  training  plans.  He  should  also 
expect  each  of  the  services  to  vigorously  defend  its 
own  approach  to  structuring  technical  orders  or 
manuals.  One  recent  concept  being  formulated  to 
minimize  the  problems  associated  with  TOs  and  TMs 
is  to  redefine  the  target  (i.e.,  using)  audience.  By 
tailoring  the  range  of  the  audience  to  include  Army, 
Navy,  and  Air  Force  personnel,  a  single  set  of  TMs 
(TOs)  may  be  used.  For  example,  a  range  would  be 
given  for  reading  levels,  skill  levels,  or  length  of 
enlistment  rather  than  a  single  specification. 
“Regardless  of  the  formats)  chosen  for  technical 
orders,  they  should  not  contain  terms  peculiar  to 
only  one  service.  Even  if  separate  manuals  must  be 
acquired  for  each  participating  service,  the  elimina¬ 
tion  of  service-peculiar  terms  allows  the  contractor  to 
better  use  the  common  data  base  and  thus  reduce 
cost.” 

Operational  Test  and  Evaluation  of  the 
Support  System 

The  approach  to  testing  and  evaluating  a  support 
system  varies  among  the  services.  The  Army  policy  is 
to  use  operational  test  and  evaluation  to  validate  the 
total  support  package  prior  to  the  production  deci¬ 
sion.  This  means  selecting  test  personnel  typical  of 
those  who  will  eventually  operate  and  maintain  the 
system,  sending  them  through  the  same  Army  con¬ 
ducted  training  programs  intended  for  equipment 
operators  and  maintainers,  providing  them  with  the 
same  technical  manuals  planned  for  publication,  and 
testing  in  the  same  operational  environment  with  the 
same  support  concepts  planned  for  fielded  systems. 
Neither  the  contractor  nor  the  developer  participate 
in  the  test  and  evaluation.  In  contrast,  Air  Force 
operational  test  and  evaluation  is  conducted  by  a 
cadre  of  well  trained,  experienced  personnel.  They 
are  assigned  to  the  program  early  enough  to  develop 
a  broad  understanding  of  the  equipment  and  a  work¬ 
ing  relationship  with  the  contractor.  The  Navy  ap¬ 
proach,  as  is  frequently  the  case,  falls  somewhere 


between  those  of  the  Army  and  Air  Force.  Testing  is 
done  in  an  operational  environment  by  military  per¬ 
sonnel  who  usually  have  been  trained  by  the  contrac¬ 
tor.  Although  support  plans,  training  plans,  and  draft 
technical  manuals  are  reviewed  as  part  of  the  test 
and  evaluation,  there  is  no  attempt  to  validate  the 
adequacy  of  the  support  system  as  is  done  in  the 
Army. 

Although  each  of  the  services  participating  in  a 
joint  program  will  do  its  own  operational  evaluation 
(and  sometimes  its  own  operational  testing),  the 
deputy  program  manager  for  logistics  will  participate 
in  preparing  the  test  and  evaluation  master  plan 
(TEMP).  He  also  will  be  responsible  for  responding 
to  the  test  findings  and  evaluations.  Throughout  the 
process  he  should  keep  in  mind  the  differences 
among  the  services  in  purpose  and  approach  to  test 
and  evaluation  and  not  be  surprised  when  require¬ 
ments,  findings,  or  recommended  corrective  actions 
conflict.  For  a  more  complete  discussion  of  test  and 
evaluation  for  a  joint  program,  see  Chapter  10. 

Generating  Interest  in  Logistics  Requirements 

The  exploration  of  alternative  support  concepts 
and  the  examination  of  reliability  and  maintainability 
are  integral  parts  of  the  prime  system  design.  Iden¬ 
tification  of  specific  support  requirements  and 
development  of  the  support  system  must  be  integral 
to  the  development  of  the  prime  system.  Frequently, 
however,  the  tendency  is  to  postpone  too  long  the 
commencement  of  logistics  planning  activities.  This 
tendency  is  not  unique  to  joint  programs,  but  the 
early  logistics  planning  for  joint  programs  also  often 
suffers  from  lack  of  interest  on  the  part  of  a  par¬ 
ticipating  service.  Especially  in  joint  programs  in 
which  there  is  no  respresentative  of  the  participating 
service  assigned  to  the  program  office,  the  par¬ 
ticipating  service  may  show  interest  in  logistics  only 
when  the  program  approaches  the  production  deci¬ 
sion  milestone.  Of  course,  many  logistics  decisions 
must  be  made  before  then.  The  program  manager 
and  deputy  program  manager  for  logistics  must  insist 
that  the  participating  service  provide  the  information 
and  support  the  program  needs. 

Personnel  and  Training 

Rarely  is  there  a  one-to-one  correspondence  be¬ 
tween  Army  Military  Occupational  Specialities 
(MOS),  Navy  Enlisted  Codes  (NEC),  and  Air  Force 
Speciality  Codes  (AFSC).  Thus,  identification  of  per¬ 
sonnel  and  training  requirements  may  be  unique  to 
each  service.  The  deputy  program  manager  for 
logistics  will  need  the  assistance  of  the  participating 
services  to  insure  that  those  requirements  are  com¬ 
patible  with  the  services’  personnel  systems, 
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operating  and  support  doctrines,  and  training 
systems.  Single  location  training  for  all  services  can 
be  cost  effective  and  should  be  considered  early  in 
the  planning  cycle. 

Depot  Maintenance  Interservicing 
Depot  Maintenance  Interservicing  (DMI)  studies 
meet  the  JLC’s  objective  for  avoidance  of  un¬ 
necessary  manpower,  equipment,  and  facility 
duplications  within  the  DOD.  Standard  policy  and 
procedures  for  DMI  are  specified  in  Chapter  12, 
SISMS.  The  DMI  new  starts  are  identified  by  the  ac¬ 
quiring  or  modifying  service.  When  the  DMI  study  is 
initiated  by  the  special  multi-service  group,  an 
analysis  is  made  to  determine  existing  capabilities 
among  the  services  compared  with  the  new  acquisi¬ 
tion  requirements.  The  DMI  requirement  should  be 
specified  in  all  applicable  contract  SOWs  and  plan¬ 
ning  documents  such  as  Joint  Integrated  Logistics 
Support  Plans. 
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CHAPTER  10 
Test  and  Evaluation 


Test  and  evaluation  (T&E)  shall  begin 
as  early  as  possible  and  be  conducted 
throughout  the  system  acquisition  proc¬ 
ess  to  assess  and  reduce  acquisition  risks 
and  to  estimate  the  operational  effective¬ 
ness  and  operational  suitability  of  the  sys¬ 
tem  being  developed  .  .  . 

Successful  accomplishment  of  T&E  ob¬ 
jectives  will  be  a  key  requirement  for  deci¬ 
sions  to  commit  significant  additional  re¬ 
sources  to  a  program  or  to  advance  it 
from  one  acquisition  phase  to  another. 
Acquisition  schedules,  financial  plans, 
and  contractual  arrangements  shall  be 
based  on  this  principle. 

This  extract  from  the  policy  section  of  Department 
of  Defense  Directive  5000.3,  “Test  and  Evaluation,” 
confirms  what  the  joint  program  manager  might  ex¬ 
pect— that  T&E  concerns  begin  early  and  mark  every 
phase  of  development,  acquisition,  and  deployment 
of  a  new  system.  T&E  is  an  integral  part  of  the  acqui¬ 
sition  process,  not  something  that  occurs  after  R&D 
is  completed.  Each  service  has  its  own  T&E  regula¬ 
tion1  which  implements  the  DOD  directive,  and 
amplifies  the  requirement  of  system  conception-to- 
fielding  test  and  evaluation.  There  is  also  a  re¬ 
quirement  in  the  United  States  Code  for  the  Secre¬ 
tary  of  Defense  to  report  certain  test  and  evaluation 
data  annually  to  Congress.2 

The  major  tasks  of  test  and  evaluation  in  a  system 
development  and  acquisition  program  are  to  assist  in 
the  design  process  of  the  system  and  to  address  the 
areas  of  risk  as  detailed  in  the  DCP  and  the  program 
charter  or  directive.  T&E  is  conducted  to  demon¬ 
strate  feasibility,  to  minimize  design  risks,  and  to 
determine  the  design  alternatives  and  trade-offs  ne¬ 
cessary  to  best  achieve  program  objectives  during  the 
demonstration  and  validation  phase  of  the  acqui¬ 
sition  process.  During  the  full-scale  development 
phase,  T&E  progresses  from  component  and  sub¬ 
system  checks  to  full  system  tests.  The  objectives 
then  are  to  further  determine  that  design  risks  are 
minimized,  that  the  system  design  is  complete,  and 
that  the  system’s  military  utility  will  justify  produc¬ 
tion.  Although  development  testing  will  predominate 
T&E  considerations  during  this  phase,  operational 


testing  must  have  been  conducted  to  satisfy  the  ques¬ 
tions  concerning  operational  effectiveness  and  suit¬ 
ability  before  a  production  decision  can  be  made. 

Background 

For  some  time  prior  to  about  1970,  the  emphasis 
in  the  acquisition  of  defense  systems  was  on  “total 
package  procurement”— a  contract  was  let  for  a  com¬ 
plete  system  development  and  procurement  program 
after  an  initial  paper  study  and  definition  phase.  The 
theory  was  that  if  a  program  or  system  was  sufficient¬ 
ly  defined  at  the  outset,  a  contractor  could  be  ex¬ 
pected  to  deliver  the  required  product  at  a  predeter¬ 
mined  cost.  Total  package  procurement  did  not  work 
well  in  practice  for  a  number  of  reasons,  including 
overoptimistic  cost  and  performance  estimates  and 
inaccurate  initial  definitions.  The  programs  often  ex¬ 
perienced  large  cost  overruns  and  significant 
performance  deficiencies. 

Several  groups— the  Blue  Ribbon  Defense  Panel, 
the  Commission  on  Government  Procurement  and 
the  Defense  Science  Board — recognized  the  deficien¬ 
cies  of  these  practices.  Partly  as  a  result  of  their 
recommendations,  new  policies  evolved  that  empha¬ 
sized  demonstrated  performance  as  the  pacing  func¬ 
tion  for  defense  acquisition  programs.  The  key  fea¬ 
ture  of  the  new  policies  is  the  periodic  review  of  the 
programs  at  critical  milestones.  During  these 
periodic  reviews  by  the  Defense  System  Acquisition 
Review  Council  (for  major  systems),  program  pro¬ 
gress  is  compared  with  program  goals  and  objectives, 
and  a  decision  is  made  to  continue,  redirect  or  can¬ 
cel  the  program.3 

For  such  comparisons  to  be  effective,  reliable  and 
accurate  measurements  of  program  progress  are  ne¬ 
cessary.  Test  and  evaluation,  the  primary  means  for 
making  such  measurements,  became  the  cornerstone 
of  the  new  acquisition  policies  and  were  emphasized 
in  their  implementation.  In  addition  to  an  OSD  T&E 
authority  being  established  (then  the  Deputy  Direc¬ 
tor  of  Defense  Research  and  Engineering  [Test  and 
Evaluation],  now  the  Director  of  Defense  Test  and 
Evaluation),  each  service  established,  or  gave  new 
emphasis  to,  independent  operational  test  agencies 
and  headquarters  staff  focal  points  for  conducting 
the  required  test  and  evaluation. 
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Types  of  Test  and  Evaluation 

The  two  principal  types  of  test  and  evaluation  con¬ 
ducted  in  the  acquisition  process  are  Development 
Test  and  Evaluation  (DT&E),  and  Operational  Test 
and  Evaluation  (OT&E).  DT&E  is  conducted  by  or 
under  the  supervision  of  the  development  agency  to 
evaluate  technical  performance  of  prototype  equip¬ 
ment.  This  testing  is  generally  conducted  by  engi¬ 
neers  and  technicians— either  contractor  or  govern¬ 
ment— in  carefully  controlled  conditions.  OT&E,  on 
the  other  hand,  is  conducted  exclusively  by  military 
personnel  to  determine  the  degree  to  which  new 
equipment  fulfills  military  operational  requirements. 
It  is,  as  a  rule,  conducted  under  conditions  that 
duplicate  as  closely  as  possible  the  environment  in 
which  the  equipment  is  expected  to  perform  when 
deployed. 

These  assessments  serve  important  functions  in 
the  acquisition  process.  DT&E  assists  in  the  actual 
design  and  development  of  a  system  in  which  initial 
designs  are  converted  to  hardware.  It  is  an  iterative 
process  of  test,  note  deficiencies,  and  fix  deficien¬ 
cies.  DT  can  be  used  to  validate— providing  the  ne¬ 
cessary  feedback  for  an  orderly  progression  from  ini¬ 
tial  design  through  engineering  model  stages  to  pro¬ 
duction  prototype.  Additionally,  DT&E  provides  in¬ 
formation  on  the  progress  of  new  system  develop¬ 
ment.  The  progress  is  ascertained  by  comparing 
measured  system  performance  with  a  set  of  technical 
goals  and  objectives  for  the  program.  A  principal 
contribution  of  DT&E,  especially  prior  to  full-scale 
development  phases,  is  the  assessment  of  alternative 
system  concepts  and  technical  approaches. 

OT&E,  like  DT&E,  also  provides  essential  infor¬ 
mation  for  decision-making  by  comparing  system  op¬ 
erational  performance  with  operational  objectives. 
Since  OT&E  is  conducted  before  system  production 
involves  testing  of  prototypes— often  competing  pro¬ 
totypes— test  results  must  be  extrapolated  to  predict 
the  operational  performance  and  suitability  of  the 
final  system. 

Combined  DT&E  and  OT&E  are  often  conducted, 
especially  early  in  the  development  of  large,  expen¬ 
sive  systems  or  systems  which  will  have  a  small 
number  produced  and  fielded.  Table  10-1  illustrates 
the  services’  T&E  phases  in  relation  to  acquisition 
milestones  and  phases. 

Production  Acceptance  Test  and  Evaluation 
(PAT&E)  is  the  third  category  of  testing  conducted 
on  production  items  to  demonstrate  that  they  meet 
contract  specifications.  PAT&E  performing  agencies 
and  methods  are  more  varied  than  those  for  pre- 
production  T&E.  Developing  agencies  sometimes 
are  responsible  for  the  conduct  of  PAT&E.  Often  the 


Defense  Contract  Administrative  Service  or  the  serv¬ 
ice  plant  representative  (e.g.,  NAVPRO  or  AFPRO) 
will  conduct  PAT&E.  In  the  Navy,  acceptance  testing 
of  ships  and  aircraft  is  the  responsibility  of  the  Board 
of  Inspection  and  Survey. 

Independent  OT&E  Agencies  and  DT&E 
Facilities 

One  of  the  key  recommendations  of  the  Blue  Rib¬ 
bon  Defense  Panel  implemented  by  SECDEF  is  the 
policy  requiring  each  service  to  maintain  a  major 
field  agency,  separate  and  distinct  from  both  the  de¬ 
veloping  or  procuring  activity  and  the  eventual  user 
activity,  to  be  responsible  for  the  conduct  of  OT&E 
and  the  monitoring  of  DT&E.  Each  such  agency  is 
required  to  report  the  results  of  independent  OT&E 
(normally  by  independent  Evaluation  Report,  IER) 
directly  to  the  service  chief,  and  to  the  Defense  Ac¬ 
quisition  Executive  when  appropriate.  The  services’ 
independent  OT&E  agencies  are  are  follows: 

— ARMY— U.  S.  Army  Operational  Test  and  Evalua¬ 
tion  Agency  (OTEA),  5600  Columbia  Pike,  Falls 
Church,  Virginia  22041 

—NAVY— Commander  Operational  Test  and  Evalua¬ 
tion  Force,  (COMOPTEVFOR),  Norfolk,  Virginia 
23511 

—MARINE  CORPS— Marine  Corps  Operational  Test 
and  Evaluation  Activity  (MCOTEA),  Quantico, 
Virginia  22134 

—AIR  FORCE— Air  Force  Test  and  Evaluation 
Center  (AFTEC),  Kirtland  Air  Force  Base,  New 
Mexico  87117 

The  foregoing  organizations  were  established  by 
the  services  to  fulfill  the  “independent  OT&E”  re¬ 
quirements  of  DOD  policy.  Each  service  has  other 
activities  that  perform  testing  functions,  generally 
within  its  development  and  acquisition  structure. 
These  activities  are  configured  and  staffed  for  tech¬ 
nical,  that  is,  development,  test,  and  evaluation. 
These  activities  are  normally  specified  for  particular 
test  support  in  a  program’s  charter  or  charter- 
implementing  documentation  (e.g.,  the  Test  and 
Evaluation  Master  Plan  [TEMP])  to  provide  test 
and/or  evaluation  support  either  independently  or  as 
monitor  agency  for  contractor  DT&E  efforts.  Some 
of  these  organizations  are  listed  in  Appendix  C. 

Initiatives  Towards  Inter-Service 
T&E  Commonality 

In  February  1978,  the  Joint  Logistics  Commanders 
(JLC)  established  a  Test  and  Evaluation  Planning 
Guidance  Ad  Hoc  Group.  Its  assigned  task  was  to 
“assess  the  current  joint  testing  environment,  deter- 
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Table  10-1 

TEST  AND  EVALUATION  PHASES 


ACQUISITION 

MILESTONE  ®  1  11  Ml 


ACQUISITION  PHASE 

CONCEPTUAL 

DEMONSTRATION 
&  VALIDATION 

FULL-SCALE 

ENGINEERING 

DEVELOPMENT 

PRODUCTION 
&  DEPLOYMENT 

ARMY  T&E 

DT  III 

DT&E 

NOT  CATEGORIZED 

DT  1 

DT  II 

PRODUCTION  TESTING 

OT&E 

NOT  CATEGORIZED 

OT  1 

OT  II 

FOE’/OT  III 

NAVY  T&E 

DT&E 

DT  1 

DT  II 

DT  IIKCTEVNTE3) 

DT  IV 

OT&E 

OT  1 

OT  II 

OT  III 

OT  IV/FOT&E* 

(SHIPS  MAY  HAVE  OT  V) 

AIR  FORCE  T&E 

DT&E 

OT&E 

- -  IOT&E - 

-  FOT&E  Is 

FOT&E  II* 

NOTES:  1.  FOE:  ARMY— FOLLOW  ON  EVALUATION 

2-  CTE  :  NAVY— CONTRACTOR  TECHNICAL  EVALUATION  (TECHEVAL) 

3.  NT  E  .  NAVY— NAVY  TECHNICAL  EVALUATION  (TECHEVAL) 

4.  FOT&E:  NAVY— FOLLOW-ON  T&E 

5.  FOT&E  I :  AIR  FORCE  — FOLLOW  ON  T&E  I 

6.  FOT&E  II:  AIR  FORC E— FOLLOW-ON  T&E  II 


mine  the  best  approach  to  resolve  deficiencies  in  ex¬ 
isting  directives,  and  develop  appropriate  policy  and 
guidance  for  greater  commonality  of  test  and  evalua¬ 
tion  effort.”  Since  the  JLC  are  individually  the  serv¬ 
ice  materia]  development  and  logistics  commanders, 
and  since  the  membership  of  the  Ad  Hoc  Group  re¬ 
presented  development  T&E  interests,  the  group’s 
implicit  focus  was  on  DT&E.  The  group  conducted  a 
thorough  review  of  current  T&E  regulations  and, 
with  the  assistance  of  its  OT&E  counterparts,  polled 
test  managers  of  over  20  joint  programs.  The  follow¬ 
ing  conclusions  emerged: 

— The  existing  multi-service  directive  (i.e.,  the  July 
1973  JLC  MOA  previously  cited)  provides  clear  and 
concise  guidance  for  management  of  joint  acquisition 
T&E  programs 

—The  current  Army,  Navy,  and  Air  Force  T&E  direc¬ 
tives  do  not  provide  guidance  consistent  with  the 
multi-service  directive 

—A  mutual  understanding  of  test  terminology  is 
essential 

A  few  direct  results  of  the  T&E  Ad  Hoc  Group’s 
work  are  in  evidence.  Changes  to  current  service 
regulations  have  been  initiated  which  will  require 
joint  program  testing  to  be  performed  in  accordance 
with  the  directives  of  the  executive  service,  consis¬ 
tent  with  the  JLC  Multi-Service  Program  Manage¬ 
ment  Directive.  A  Compendium  of  Test  Terminology 


was  compiled,  published,  and  made  available  to  the 
T&E  community.4  Every  joint  program  manager  and 
multi-service  T&E  director  will  find  the  compendium 
invaluable. 

A  Multi-Service  DT&E  Commanders’  Conference 
recommended  that  the  Ad  Hoc  Group  become  a  per¬ 
manent  joint  acquisition  DT&E  interface  and  focal 
point  with  the  JLC.  That  recommendation  was  im¬ 
plemented  by  the  issuance  of  a  joint  regulation5 
which  requires  semi-annual  meetings  of  the  Group, 
undertaking  of  items  recommended  by  the  recurring 
Multi-Service  DT&E  commanders’  Conference,  an¬ 
nual  review  of  the  Compendium  of  Terms  and  coor¬ 
dination  with  the  OT&E  community  on  appropriate 
issues. 

This  is  the  first  such  initiative  in  the  military  test 
community  and  is  expected  to  be  the  precursor  to  a 
greater  degree  of  consistency  in  acquisition  testing. 
The  joint  program  manager  and  his  test  organization 
should  take  advantage  of  the  continuing  work  done 
by  the  Group,  whose  members  are: 

Air  Force 

— HQ  AFSC/TEVP  (Office  of  primary  responsibility 
Andrews  AFB  for  convening  meetings) 

Washington,  D.C.  20334 
-HQ  AFLC/LOE 
Wright-Patterson  AFB 
Ohio  45433 
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Army 

— DARCOM/DRDCE-RT 
5001  Eisenhower  Avenue 
Alexandria,  Virginia  22333 
-TECOM/DRSTE-TO-P 
Aberdeen  Proving  Ground 
Maryland  21005 

Navy 

— NMC/MAT  08D2 
Washington,  D.C.  20360 
— NMC/AIR  6101 
Washington,  D.C.  20361 

Marine  Corps 

—Director,  Development  Center  D050-3 
MCDEC 

Quantico,  Virginia  22134 

Coincidental  to  this  work  towards  commonality  in 
development  T&E,  the  OT&E  Commanders,  who 
currently  meet  to  discuss  mutual  issues  on  a  quarter¬ 
ly  basis,  appointed  an  Ad  Hoc  Group  for  Joint  Serv¬ 
ice  Testing  in  July  1978.  This  Group  has  produced  a 
Memorandum  of  Agreement  on  Multi-Service  OT&E 
and  Joint  T&E,  cited  later  in  this  chapter,  and  in¬ 
tends  to  expand  the  agreements,  as  well  as  address 
other  areas  highlighted  by  the  OT&E  Commanders. 

There  is  great  potential  for  misunderstanding  the 
Multi-Service  environment  because  common  or  near¬ 
ly  common  terms  do  not  always  have  the  same  mean¬ 
ing  in  the  different  services.  For  example,  consider 
the  (deceptively)  simple  word  “initial.”  When  in¬ 
cluded  in  a  phrase  that  has  wide  application  and 
understanding  such  as  initial  Operational  Capability 
(IOC)  the  Joint  Dictionary6  meaning  prevails,  and 
mutual  understanding  is  facilitated.  But  unique  appli¬ 
cation  of  the  work  in  another,  single-service  environ¬ 
ment  may  give  rise  to  misunderstanding.  The  Army 
describes  IOC  FDTE7  as  a  test  activity  which  is  con¬ 
ducted  subsequent  to  a  full  production  decision.  The 
Navy8  and  the  Air  Force9  both  describe  Initial  Opera¬ 
tional  Test  and  Evaluation  (IOT&E)  as  a  test  activity 
conducted  prior  to  a  first  major  production  decision. 
It  is  easy  to  imagine  the  difficulties  that  could  stem 
from  several  services  planning  a  test  program  for  a 
jointly  developed  system  unless  these  concepts  of 
“initial”  testing  were  recognized  and  resolved. 
Recognition  and  resolution  now  have  a  starting 
point:  A  Compenium  of  Test  Terminology. 

As  a  rule,  particular  communities  throughout  the 
services  are  aware  of  service-peculiar  practices.  Ac¬ 
tivities  which  cut  across  service  borders,  such  as 
those  undertaken  by  professional  societies  and  the 
Joint  Logistics  Commanders  have  promoted  wider 
understanding  of  service-peculiar  concepts  and  ter¬ 


minology  by  members  of  specific  disciplines  such  as 
financial  managers  and  logisticians.  Of  course,  these 
disciplines  occasionally  develop  phraseology  whose 
shades  of  meaning  are  understood  within  the  com¬ 
munity,  but  not  outside,  irrespective  of  service  as¬ 
sociation.  The  operational  testing  community,  for  in¬ 
stance,  has  found  it  necessary  to  make  a  specific  dis¬ 
tinction  between  “joint  testing”  and  “multi-service” 
testing.  The  commanders  of  the  services’  inde¬ 
pendent  operational  test  organizations  have  agreed 
that  “joint  T&E”  means  “an  OSD  directed  and  par¬ 
tially  funded  non-acquisition  T&E  program  struc¬ 
tured  to  evaluate  system  operational  or  technical 
performance  under  realistic  conditions  with  two  or 
more  services  participating  or  with  interre¬ 
lated/interacting  systems.”  “Multi-Service  OT&E” 
means  “OT&E  conducted  jointly  by  two  or  more 
services  for  systems  to  be  acquired  by  more  than  one 
service,  or  for  a  service’s  systems  which  have  inter¬ 
faces  with  equipment  of  another  service.”10  This 
distinction  was  made  to  allow  the  service  test  organi¬ 
zations  to  differentiate  between  their  acquisition- 
oriented  test  activity  and  that  mandated  by  Depart¬ 
ment  of  Defense  Directive  5000.3  under  the  direc¬ 
tion  of  the  Director  of  Defense  Test  and  Evaluation. 
Thus  the  manager  of  a  joint  service  acquisition  pro¬ 
gram  will  probably  be  advised  that  “multi-service” 
rather  than  “joint  testing”  must  be  accomplished  to 
fulfill  the  program’s  requirements. 

Test  and  Evaluation  Master  Plan 

—The  Test  and  Evaluation  Master  Plan  (TEMP)  re¬ 
quired  by  Department  of  Defense  Directive  5000.3  is 
recognized  throughout  the  test  community  as  the 
controlling  management  document  for  identification 
and  integration  of  all  objectives,  responsibilities,  re¬ 
sources,  and  schedules  for  all  aspects  of  T&E.  In 
some  cases,  the  name  of  the  document  has  recently 
changed— the  Army  forerunner  to  the  TEMP  was  the 
Coordinated  Test  Program  (CTP). 

—The  TEMP  is  a  formal,  stand-alone  and  dynamic 
document.  Department  of  Defense  directive  5000.3 
includes  guidelines  for  the  content  and  format  of 
TEMPs.  Briefly,  the  TEMP,  or  combination  of 
TEMP  supporting  documents  (System  Test  Plan 
[STP],  and  Program  Introduction  Document 
[PID]-Air  Force,  Outline  Test  Plan  [OTP],  and  Test 
Design  Plan  [TDP-Army])  must  contain: 

—System  description  and  intended  operational 
mission 

—Critical  T&E  issues 

—Test  objectives 

—  Required  technical  and  operational 
characteristics,  goals,  and  thresholds 
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—Integrated  schedule  including  contracting  dem¬ 
onstrations,  preliminary  evaluations  (Navy),  technical 
evaluations  (Navy),  Qualification  OT&E  (Air  Force), 
in-process  review  (Army,  less-than-major  systems), 
type  classification  (Army),  approval  for  service  use 
(Navy),  as  well  as  required  “standard”  development 
and  operational  T&E  and  program  milestones 

— T&E  resources  required,  including  laboratory, 
ranges,  test  sites,  instrumentation,  major  command 
or  fleet  (Navy)  support  needs,  personnel,  personnel 
training,  logistic  support,  and  funding  by  program 
element  and  appropriation  perfiscal  year 

For  major  acquisition  programs,  OSD  approval  of 
the  TEMP  is  a  requirement  for  Milestone  I  and  all 
subsequent  milestones.  Air  Force  Regulation  80-14 
requires  a  TEMP  for  all  Headquarters  Air  Force 
directed  programs.  Clearly  the  TEMP,  like  the  Pro¬ 
gram  Management  Plan  (or  Joint  Development  Plan) 
which  it  supports,  as  well  as  the  Integrated  Logistics 
Support  Plan,  must  be  started  early.  The  Test  Divi¬ 
sion  (Directorate  or  Joint  Test  Office),  of  the  joint 
program  office  must  work  in  close  cooperation  with 
the  Executive  Service  organizations  responsible  for 
DT&E  and  OT&E,  as  specified  earlier  in  this  chap¬ 
ter.  These  organizations  must  integrate  test  and  eval¬ 
uation  requirements  of  the  specific  program  with 
those  of  other  programs.  Lead  times  for  this  plan¬ 
ning  and  integration  can  be  long;  for  instance  the 
Army’s  Test  Schedule  and  Review  Committee  con¬ 
siders  the  coordination  among  OT&E  requirements 
and  resources  for  a  5  year  period.  Initial  versions  of 
TEMPs  will  lack  many  specifics,  but  the  iterative  re¬ 
vision  process  will  develop  the  necessary  detail. 

Multi-Service  T&E  Considerations 

Service  T&E  directives  specify  that  its  T&E  regula¬ 
tions  will  be  followed  for  multi-service  testing  for 
which  it  is  the  lead  service  (e.g.,  OPNAVINST 
3960.10  states:  “All  such  JT&E  for  which  the  Navy  is 
the  lead  service  will  be  planned,  accomplished  in  ac¬ 
cordance  with  [Department  of  Defense  Directive 
5000.3]  and  this  instruction,  unless  otherwise 
directed.”)  In  general,  service  guidance  is  not  pro¬ 
vided  when  the  specific  service  is  not  the  lead  serv¬ 
ice.  The  joint  program  manager  and  his  test  manager 
should  be  alert  for  the  issue  of  changes  recom¬ 
mended  by  the  Ad  Hoc  Group  so  that  all  members  of 
the  test  group  will  have  consistent  direction,  and  all 
branches  and  levels  of  the  participating  services  are 
aware  of  their  service  policy  to  use  the  Executive 
Service  test  planning  procedure. 

The  joint  program  manager  should  expect  his  test 
manager  to  promote  specific  testing  by  a  single,  con¬ 
solidated — that  is,  with  all  interested  services  par¬ 


ticipating— test  group  whose  reports  would  be  avail¬ 
able  to  service  agencies  for  independent  evaluations. 
(The  procedure  of  “joint  testing  and  independent 
evaluation”  was  a  specific  recommendation  of  the 
Defense  Science  Board’s  Acquisition  Cycle  Task 
Force.)11  Championing  that  cause  might  be  one  of 
the  most  significant  acts  a  joint  program  manager 
can  perform  to  prevent  proliferation  of  separate  serv¬ 
ice  testing  from  slowing  his  program. 

Footnotes 

1.  Army  Regulation  70-10,  “Test  and  Evaluation  during  Development 
and  Acquisition  of  Materiel,"  and  AR  71-3,  OPNAVINST  3960. 10A, 
“Test  and  Evaluation/'  31  July  1981.  Air  Force  Regulation  80-14,  Test 
and  Evaluation."  Marine  Corps  Order  5000.11  A,  “Testing  and  Evalua¬ 
tion  of  Systems  and  Equipment  for  the  Marine  Corps,"  2  July  1979. 

2.  Section  139,  Chapter  4  of  Title  10,  United  States  Code  was 
amended  by  the  FY  1974  Acquisition  Act  to  require  SECDEF  to  report 
to  Congress  operational  testing  and  evaluation  data  on  weapons  systems 
for  which  procurement  funds  are  requested. 

3.  See  Chapter  5,  “Program  Review,”  for  detailed  description  of  the 
DSARC  review  process. 

4.  Compendium  of  Test  Terminology,  December  1978.  Compiled  by 
the  Joint  Logistic  Commanders  Ad  Hoc  Group  on  Test  and  Evaluation 
Planning  Guidance,  Defense  Documentation  Center  reference,  ADA 
065-412 

5.  AFSC/AFLC  Regulation  80-24/DARCOM  Regulation 
70-64/NAVMATINST  3970.1/USMC  Development  Center  Order  5000.2, 
15  May  1979,  “Joint  Service  Interface  on  Development  Test  and  Evalua¬ 
tion.” 

6.  JCS  PUB  1,  Joint  Dictionary.  “Initial  Operational  Capability— the 
first  attainment  of  the  capability  to  employ  effectively  a  weapon,  item  of 
equipment,  or  system  of  approved  specific  characteristics,  and  which  is 
manned  or  operated  by  an  adequately  trained,  equipped  and  supported 
military  unit  for  force." 

7.  Army  Regulation  (AR)  71-3,  “TOC  Force  Development  Testing 
and  Experimentation,”  ICO  FDTE. 

8.  OPNAVINST  3960.10,  op.  cit 

9.  Air  Force  Manual  (AFM)  11-1,  “U.S.  Air  Force  Glossary  of  Stand¬ 
ardized  Terms." 

10.  Memorandum  of  Agreement  on  Multiservice  OT&E  and  Joint 
T&E,  27  March  1979  by  Commander  U.S.  Army  Oprational  Test  and 
Evaluation  Agency  (OTEA),  Commander  Operational  Test  and  Evalua¬ 
tion  Force  (COMOPTEVFOR),  Commander,  Air  Force  Test  and  Evalua¬ 
tion  Center  (AFTEC),  and  Director,  Marine  Corps  Operational  Test  and 
Evaluation  Activity  (MCOTEA). 

11.  Report  of  the  Acquisition  Cycle  Task  Force,  Defense  Science 
Board,  15  March  1978. 
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CHAPTER  11 
Department  of  Defense 

Acquisition  Improvement 
Program 

(Reprint)1 


We  stand  at  a  singular  point  in  time.  We  have  a 
unique  opportunity  to  significantly  improve  the  de¬ 
fense  of  our  nation.  It  appears  that  there  is  the 
prevailing  view  among  the  American  people  that  a 
larger  percentage  of  our  gross  nat.1  laJ  product 
should  be  spent  on  defense.  At  the  sa  2  time,  we 
have  been  strongly  alerted  that  we  must  be  good 
stewards  of  our  resources.  In  a  fiscal  year  in  which 
the  DOD  budget  is  scheduled  to  grow  substantially, 
almost  all  other  federal  agencies  will  experience  sub¬ 
stantial  budgetary  cuts.  With  these  gigantic,  counter¬ 
vailing  forces  at  work,  the  window  available  to  us  to 
make  major  advances  in  our  preparedness  may  be 
very  short— possibly  as  short  as  1  or  2  years. 

In  full  appreciation  of  this  environment  and  its  im¬ 
plications,  Deputy  Secretary  of  Defense  Frank  C. 
Carlucci  took  action.  On  2  March  1981,  he  chartered 
five  working  groups— involving  all  of  the  services  and 
inviting  inputs  from  industry— to  make  recommenda¬ 
tions  with  regard  to  improving  the  acquisition  proc¬ 
ess.  The  report  of  the  working  groups  was  delivered 
on  31  March  1981.  Mr.  Carlucci’s  response  to  the  re¬ 
port  is  best  stated  in  his  own  words:  “I  have  dis¬ 
cussed  the  report  with  the  Steering  Group,  the  Joint 
Chiefs  of  Staff,  the  Service  Secretaries,  and  the 
Under  Secretaries  and  selected  Assistant  Secretaries 
of  Defense.  Based  on  the  report  and  those  meetings, 
the  Secretary  and  I  have  decided  to  make  major 
changes  both  in  acquisition  philosophy  and  the  ac¬ 
quisition  process  itself.”  On  30  April  1981,  Mr. 
Carlucci  issued  his  decisions  and  identified  31  ac¬ 
tions  for  implementation  by  DOD.  Mr.  Carlucci 
signed  one  more  action  on  27  July  1981,  yielding  the 
current  total  of  32  (see  Figure  11-1).  The  actions 
became  effective  on  the  dates  they  were  signed. 

The  purpose  of  this  paper  is  to  provide  the  pro¬ 
gram  manager  with  a  working  knowledge  of  these  32 
actions  to  improve  defense  acquisition.  At  the  outset, 
it  should  be  noted  that  while  these  actions  compose  a 
well-reasoned  set,  they  are  by  no  means  all  inclusive; 
they  address  many  of  the  crucial  acquisition  manage¬ 
ment  problems,  but  leave  many  important  problems 
unsolved.  It  is  at  this  point  that  the  program  manager 


can  play  a  particularly  vital  role  by  building  on  the  32 
actions,  to  point  the  way  to  many  other  actions  to  im¬ 
prove  the  acquisition  process. 

The  32  acquisition  improvement  actions  fall  into 
several  classes.  Many  of  the  actions  have  already 
been  implemented  and  the  effects  are  already  being 
felt  in  the  field;  others  require  high-level  (e.g.  con¬ 
gressional)  approval  or  acquiescence.  Ultimately,  the 
program  manager  will  benefit  from  these  actions,  but 
meanwhile,  there  is  nothing  he  can  do  except  re¬ 
spond  to  requests  for  data  and  supporting  evidence. 

By  far  the  most  important  actions,  however,  are 
those  which  require  decisions  on  the  part  of  the  pro¬ 
gram  manager.  These  decisions  will  be  based  largely 
on  the  answers  to  two  questions:  (1)  Is  this  action  ap¬ 
plicable  to  my  program?  and  (2)  What  measures  can 
or  should  I  take  in  response  to  this  action? 

Before  proceeding  any  further,  it  is  appropriate  to 
note  that  we  have  seen  many  of  these  words  before. 
Accordingly,  we  have  every  right  to  ask,  “So  what  is 
different  this  time?”  The  difference  is  this:  Mr. 
Carlucci  has  also  heard  the  rhetoric  many  times,  and 
is  determined  to  replace  rhetoric  with  actions.  The 
Department  of  Defense  is  prepared,  perhaps  more 
than  ever  before,  to  demonstrate  by  its  actions  its 
commitment  to  the  principles  of  effective  systems 
management.  Indeed,  the  DOD  has  already  demon¬ 
strated  its  commitment  by  a  series  of  far-reaching 
measures.  And  the  activity  associated  with  imple¬ 
menting  the  remaining  actions  can  best  be  described 
as  “intense.”  The  current  revision  of  DOD  Directive 
5000.1,  scheduled  for  late  this  calendar  year,  is  an 
expression  of  the  urgently  felt  need  to  use  every 
available  forum  to  describe  the  letter  and  intent  of 
the  acquisition  improvement  actions. 

Background 

One  of  Mr.  Carlucci’s  first  actions  upon  arriving  in 
the  Department  of  Defense  was  to  ask  people  in  the 
acquisition  community  to  identify  their  most  serious 
concerns.  He  received  answers  from  all  sectors,  from 
Congress  to  the  program  manager.  He  found  con¬ 
cerns  with  program  turbulence,  and  the  extraordi- 
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Figure  11-1 

ACQUISITION  IMPROVEMENT  ACTIONS 


1.  REAFFIRM  ACQUISITION  MANAGEMENT  PRINCIPLES 

2.  INCREASE  USE  OF  PREPLANNED  PRODUCT  IMPROVEMENT 

3.  IMPLEMENT  MULTIYEAR  PROCUREMENT 

4.  INCREASE  PROGRAM  STABILITY 

5.  ENCOURAGE  CAPITAL  INVESTMENT  TO  ENHANCE  PRODUCTIVITY 

6.  BUDGET  TO  MOST  LIKELY  COSTS 

7.  USE  ECONOMICAL  PRODUCTION  RATES 

8.  ASSURE  APPROPRIATE  CONTRACT  TYPE 

9.  IMPROVE  SYSTEM  SUPPORT  AND  READINESS 

10.  REDUCE  ADMINISTRATIVE  COSTS  AND  TIME 

11.  BUDGET  FOR  TECHNOLOGICAL  RISK 

12.  PROVIDE  FRONT-END  FUNDING  FOR  TEST  HARDWARE 

13.  REDUCE  GOVERNMENTAL  LEGISLATION  RELATED  TO  ACQUISITION 

14.  REDUCE  NUMBER  OF  DOD  DIRECTIVES 

15.  ENHANCE  FUNDING  FLEXIBILITY 

16.  PROVIDE  CONTRACTOR  INCENTIVES  TO  IMPROVE  RELIABILITY  AND  SUPPORT 

17.  DECREASE  DSARC  BRIEFING  AND  DATA  REQUIREMENTS 

18.  BUDGET  FOR  INFLATION 

19.  FORECAST  BUSINESS  BASE  CONDITIONS 

20.  IMPROVE  SOURCE  SELECTION  PROCESS 

21.  DEVELOP  AND  USE  STANDARD  OPERATION  AND  SUPPORT  SYSTEMS 

22.  PROVIDE  MORE  APPROPRIATE  DESIGN-TO-COST  GOALS 

23.  IMPLEMENT  ACQUISITION  PROCESS  DECISIONS 

24.  REDUCE  DSARC  MILESTONES 

25.  SUBMIT  MENS  WITH  SERVICE  POM 

26.  REVISE  DSARC  MEMBERSHIP 

27.  RETAIN  USDRE  AS  DEFENSE  ACQUISITION  EXECUTIVE 

28.  RAISE  DOLLAR  THRESHOLDS  FOR  DSARC  REVIEW 

29.  INTEGRATE  DSARC  AND  PPBS  PROCESS 

30.  INCREASE  PM  VISIBILITY  OF  SUPPORT  RESOURCES 

31.  IMPROVE  RELIABILITY  AND  SUPPORT 

32.  INCREASE  COMPETITION 


nary  difficulty  we  have  with  holding  to  our  long-range 
plans.  He  found  concerns  with  the  burden  of  report¬ 
ing  and  reviewing,  and  with  the  seemingly  endless 
rounds  of  briefings.  He  found  concerns  with  the  cost 
of  acquisitions,  particularly  the  overhead  and  indi¬ 
rect  costs,  and  with  our  inability  to  estimate  costs  re¬ 
alistically.  He  found  concerns  with  the  aging  and 
shrinking  industrial  base.  He  found  concerns  with 
the  length  of  the  acquisition  process,  occasioned  by 
many  causes  (sometimes  by  technical  difficulties, 
sometimes  by  the  decision-making  process,  often  by 
the  constraints  of  the  budget  process).  He  found  con¬ 
cerns  with  the  cost  of  ownership,  including  the  costs 
of  maintenance  and  support.  And  finally,  he  found 
concerns  that  performance  and  readiness  of  systems 
in  the  field  and  in  the  fleet  were  far  below  the  level 
anticipated  and  needed. 

At  the  same  time,  Mr.  Carlucci  was  keenly  aware  of 


the  numerous  studies  of  the  acquisition  process  that 
had  been  conducted  over  the  past  decade  (Figure 
11-2).  In  his  view,  we  did  not  need  another  study— 
the  time  for  action  had  arrived.  It  would,  of  course, 
be  wrong  to  suggest  that  during  the  last  decade  no 
progress  had  been  made  in  refining  the  acquisition 
process.  The  publications  of  DOD  Directive  5000.1 
and  of  OMB  Circular  A-109  were  major  achieve¬ 
ments  in  the  definition  and  refinement  of  the  acquisi¬ 
tion  process.  Of  particular  note  in  both  of  these 
documents  is  the  strong  emphasis  on  tailoring  the  ac¬ 
quisition  process  to  yield  the  optimum  acquisition 
strategy.  In  spite  of  such  improvements,  however, 
Mr.  Carlucci’s  view  was  that  in  the  past  too  much  em¬ 
phasis  had  been  put  on  studying  problems  and  too 
little  on  implementing  solutions.  Thus,  the  five  work¬ 
ing  groups  were  chartered  not  to  conduct  yet  another 
study  of  the  acquisition  process,  but  to  look  at  solu- 
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Figure  11-2 

MAJOR  STUDIES  OF  THE  ACQUISITION  PROCESS 
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tions  that  had  been  proposed  in  the  past  and  deter¬ 
mine  a  course  for  future  actions.  Out  of  these  study 
groups’  findings  and  recommendations  came  the  32 
actions  designed  to:  (1)  promote  decentralization 
and  participative  management,  (2)  improve  the  plan¬ 
ning  and  execution  of  weapon  system  programs,  (3) 
strengthen  the  industrial  base  that  supports  the 
Department  of  Defense,  (4)  increase  the  readiness  of 
weapon  systems,  particularly  in  the  early  stages  of 
their  lives  in  the  field,  and  (5)  reduce  the  burden¬ 
some  administrative  requirements  that  make  the  ac¬ 
quisition  process  more  costly  and  time-consuming 
than  necessary. 

The  32  Acquisition  Improvement  Actions 

Now  let’s  look  more  closely  at  the  specific  actions. 
We  will  not  examine  them  all  in  detail  or  in  numeri¬ 
cal  order,  but  will  instead  consider  them  as  they 
relate  to  the  five  primary  objectives  listed  in  the  pre¬ 
vious  paragraph. 

The  32  acquisition  improvement  actions  are  firmly 
rooted  in  eight  fundamental  management  principles 
(see  Actions  1  and  32).  These  principles  were  stated 
by  Mr.  Vincent  Puritano,  Executive  Assistant  to  the 


Deputy  Secretary  of  Defense,  in  an  article  in  the 
October  1981  issue  of  Defense/81  as  follows: 

We  must  improve  long-range  planning 
to  enhance  acquisition  program  stability. 

Both  OSD  and  the  Services  must  dele¬ 
gate  more  responsibility,  authority  and 
accountability  for  programs;  in  particular, 
the  Service  program  manager  should 
have  the  responsibility,  authority  and 
resources  adequate  to  execute  efficiently 
the  program  for  which  he  is  responsible. 

We  must  examine  evolutionary  alterna¬ 
tives  which  use  a  lower  risk  approach  to 
technology  than  solutions  at  the  frontier 
of  technology, 

We  must  achieve  more  economic  rates 
of  production. 

We  must  realistically  cost,  budget,  and 
fully  fund  in  the  Five  Year  Defense  Plan, 
and  Extended  Planning  Annex,  procure¬ 
ment,  logistics  and  manpower  for  major 
acquisition  programs. 

Readiness  and  sustainability  of  de¬ 
ployed  weapons  are  primary  objectives 
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and  must  be  considered  from  the  start  of 
weapon  system  programs. 

A  strong  industrial  base  is  necessary  for 
a  strong  defense.  The  proper  arms-length 
relationships  with  industry  should  not  be 
interpreted  by  DOD  or  industry  as  adver¬ 
sarial. 

Defense  managers  at  all  levels  should  expand  their 
efforts  to  obtain  maximum  competition  for  their  con¬ 
tractual  requirements. 

Promote  Decentralization  and 
Participative  Management 

The  first  group  of  actions  reflects  what  has  been 
variously  called  “controlled  decentralization”  and 
“participative  management,”  and  is  in  line  with 
Deputy  Secretary  Carlucci’s  desire  for  a  major 
change  in  acquisition  philosophy. 

Our  current  way  of  doing  business  reflects  two 
decades  of  increasing  centralization.  We  have  seen 
an  increase  in  the  number  of  reports  and  briefings; 
we  have  observed  an  increase  in  the  number  of  direc¬ 
tives  and  regulations;  and  we  have  experienced  de¬ 
lays  in  the  decision-making  process. 

To  illustrate  this  point,  consider  the  data  in  Fig¬ 
ure  11-3,  which  illustrates  the  tortuous,  time- 
consuming  path  to  a  Defense  Systems  Acquisition 
Review  Council  (DSARC)  review.  In  fact,  very  few  of 
these  prebriefings  are  actually  presented  to  offices 
within  the  Office  of  the  Secretary  of  Defense;  most 
are  offered  to  line  and  staff  organizations  within  the 
services. 

Lest  there  be  a  misunderstanding,  it  should  be 
noted  that  centralization  has  its  distinct  advantages. 
Moreover,  every  new  regulation,  policy,  and  pro¬ 
cedure  is  conceived  with  the  objective  of  helping  us 
avoid  a  pitfall.  However,  we  have  become  so  superbly 
conscious  of  avoiding  errors  that  we  have  added  a 
heavy  overburden  to  our  process.  (Note  that  in  geol¬ 
ogy,  “overburden”  refers  to  the  material  that  must  be 


removed  before  one  gets  to  the  mineral-bearing  ore 
in  a  mine.) 

The  objective  of  this  thrust  is  to  reverse  some  ele¬ 
ments  of  the  trend  towards  centralization.  A  particu¬ 
larly  definitive  statement  of  the  Deputy  Secretary’s 
intent  is  provided  in  his  27  March  memorandum; 
“We  will  achieve  better  defense  management  by 
working  toward  a  system  of  centralized  control  of  ex¬ 
ecutive  policy  direction  and  more  decentralized  po¬ 
licy  execution  (emphasis  added).”  Thus,  there  is  a 
clear  delineation  of  responsibility:  There  are  some 
decisions  which  clearly  should  be  reserved  for  the 
highest  levels;  however,  in  most  cases,  decisions  can 
and  should  be  made  at  substantially  lower  levels  in 
the  organization.  The  succinct  guideline  for  this 
distinction  is  stated  in  one  of  the  management  prin¬ 
ciples  within  Action  1:  “Responsibility,  authority  and 
accountability  for  programs  should  be  at  the  lowest 
levels  of  the  organization  at  which  a  total  view  of  the 
program  rests.” 

The  following  five  actions  directly  support  this 
thrust; 

24.  Reduce  the  number  of  Secretary  of  Defense 
decisions. 

28.  Raise  the  dollar  threshold  used  to  select 
major  programs  for  DSARC  review. 

17.  Decrease  DSARC  briefing  and  data  re¬ 
quirements. 

26.  Revise  DSARC  membership  to  include  the 
appropriate  service  secretary. 

27.  Retain  the  Under  Secretary  of  Defense  for 
Research  and  Engineering  as  the  Defense 
Acquisition  Executive  (DAE). 

Action  24  cuts  in  half  the  number  of  Secretary  of 
Defense  decisions  for  major  weapon  system  pro¬ 
grams  and  reduces  the  number  of  DSARC  reviews 
from  three  to  two.  The  new  process,  illustrated  by 
Figure  11-4,  is  already  in  force.  Four  features 
deserve  special  attention. 

(1)  Note  that,  although  the  Mission  Element  Need 
Statement  (MENS)  is  no  longer  specifically  approved 
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Figure  11-4 

MAJOR  SYSTEMS  ACQUISITION  PROCESS 
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by  the  Secretary  of  Defense  (Milestone  0),  the  new 
procedure  requires  that  the  MENS  be  submitted  with 
the  service  program  objectives  memorandum  (POM). 
Thus,  the  Secretary  of  Defense  does  tacitly  approve 
the  MENS  when  he  approves  the  POM. 

(2)  The  new  milestone,  entitled  Requirement 
Validation,  is  effectively  the  same  as  the  old 
Milestone  I,  Alternative  Selection. 

(3)  The  new  milestone  entitled  Program  Go-Ahead 
is  no  longer  rigidly  tied  to  the  beginning  of  the  full- 
scale  development  phase  of  the  program.  The  objec¬ 
tive  of  this  new  arrangement  is  to  allow  the  program 
manager  more  flexibility  in  the  development  of  his 
acquisition  strategy.  On  the  one  hand,  he  may  wish 
to  stick  with  the  traditional  definition  of  Milestone  II. 
On  the  other  hand,  he  may  wish  to  delay  the  Pro¬ 
gram  Go-Ahead  Milestone  until  after  preliminary 
design  review  (PDR)  or  even  after  complete  design 
review  (CDR)  so  that  he  can  develop  a  better  view  of 
the  performance,  cost,  schedule,  industrial  base  pre¬ 
paredness,  supportability,  and  testing  prior  to  the 
Secretary  of  Defense  decision  to  commit  to  comple¬ 
tion  of  full-scale  development,  production,  and  de¬ 
ployment.  Normally  the  acquisition  strategy,  and 
hence  the  timing  of  the  Program  Go-Ahead  mile¬ 
stone,  will  be  defined  and  agreed  upon  at  the  Re¬ 
quirement  Validation  milestone.  Regardless  of  the 
timing  of  the  Program  Go-Ahead  Milestone,  all  con¬ 
tractual  instruments  must  be  responsive  to  the  deci¬ 
sions  of  the  Secretary  of  Defense  and,  for  example, 
provide  for  the  termination  of  the  program  at  the 
Program  Go-Ahead  milestone  (should  the  Secretary 
of  Defense  make  this  decision).  (Needless  to  say,  the 


intent  of  this  action  is  not  to  create  another  mile¬ 
stone;  the  Program  Go-Ahead  Milestone  replaces  the 
Intend  to  Deploy  milestone). 

(4)  The  old  Production  Decision  milestone  has 
been  returned  to  the  services  with  the  following  pro¬ 
viso:  The  program  must  be  within  performance,  cost, 
and  schedule  windows  established  at  the  Progam  Go- 
Ahead  milestone. 

In  a  related  action,  the  thresholds  for  programs  to 
qualify  for  DSARC  review  have  been  doubled.  The 
new  thresholds  are  $200  million  in  research,  devel¬ 
opment,  test  and  evaluation  funds  and  $1  billion  in 
procurement  funds.  Note  that  the  revised  thresholds 
are  stated  in  terms  of  FY  80  dollars;  thus  there  is  a 
built-in  “cost  of  business”  adjustment.  This  action 
has  resulted  in  10  programs  being  removed  from  the 
DSARC  review  process. 

A  brief  note  is  in  order  regarding  the  major  pro¬ 
grams  which  were  initiated  “pre-Carlucci”  and  are 
not  below  the  new  DSARC  review  thresholds.  These 
programs  are  being  examined  on  a  case-by-case  basis 
to  determine  whether  further  OSD  reviews  are  war¬ 
ranted.  It  is  interesting  to  note  in  this  regard  that,  in 
several  cases  (the  KC-135  re-engining  and  the  Toma¬ 
hawk  programs,  for  example),  the  Milestone  III  re¬ 
view  has  been  delegated  to  the  services. 

Some  progress  is  also  being  made  in  reducing  the 
amount  of  material  that  will  be  prepared  for  a  typical 
DSARC  review.  For  example,  the  integrated  program 
summary  (IPS)  has  been  eliminated  for  the  Require¬ 
ment  Validation  reviews;  this  action  will,  of  course, 
require  that  the  corresponding  decision  coordinating 
paper  (DCP)  contain  complete  cost  information  on 
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Figure  11-5 
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the  alternatives  to  be  considered.  Dr.  Richard  D. 
DeLauer,  Under  Secretary  of  Defense  for  Research 
and  Engineering,  is  also  examining  the  possibility  of 
shortening  the  IPS  for  the  Program  Go-Ahead  re¬ 
views  scheduled  to  be  held  at  OSD. 

In  a  fourth  action  dealing  with  the  DSARC  proc¬ 
ess,  the  membership  of  the  DSARC  has  been  in¬ 
creased  to  give  the  services  a  greater  voice  in  the 
DSARC  process.  As  noted  in  Figure  1 1-5,  the  service 
secretary  of  the  appropriate  service  has  been  added 
to  the  DSARC  membership.  In  the  case  of  joint- 
service  programs  such  as  the  advanced  medium 
range  air-to-air  missile  (AMRAAM)  program,  the  sec¬ 
retaries  of  all  involved  services  will  be  members  of 
the  Council. 

Improving  Planning  and  Execution 

The  root  cause  of  difficulties  in  the  area  of  plan¬ 
ning  and  execution  is,  of  course,  uncertainty.  Tech¬ 
nical  uncertainties  are  the  most  commonly  cited. 
Technical  uncertainties  can  also  lead  to  schedule 
uncertainties;  however,  there  are  other  sources  of 
schedule  uncertainty.  Foremost  among  these  is  the 
necessity  to  stretch  out  a  program  in  order  to  accom¬ 
modate  all  of  the  desired  programs  within  the  con¬ 
straints  of  a  fixed  budget.  Cost  uncertainties  arise 
both  from  technical  uncertainties  and  also  from 
schedule  uncertainties.  But  cost  uncertainties,  like 
schedule  uncertainties,  have  independent  origins  of 
their  own.  In  some  cases,  we  are  simply  not  able  to 
estimate  with  the  desired  accuracy  the  future  cost  of 
research  and  development  or  of  production  pro¬ 
grams. 

Common  techniques  for  coping  with  uncertainties 
are  well  known.  We  adjust  production  rates  annually; 
we  cut  soft  programs  in  order  to  make  funds  avail¬ 
able  to  other  programs;  we  delete  hardware  items 
such  as  test  hardware,  and  so  forth.  Among  the  con¬ 


sequences  of  these  actions  are  program  turbulence 
and  cost  growth.  The  extent  of  turbulence  in  the  47 
major  programs  reported  in  the  Selected  Acquisition 
Reports  (SARs)  dated  30  June  1981  is  illustrated  by 
the  following  data:  With  respect  to  the  acquisition 
strategy  laid  down  at  Milestone  II,  40  of  the  programs 
have  experienced  changes  in  the  number  of  units  to 
be  procured,  and  41  of  the  programs  have  experi¬ 
enced  schedule  changes.  Cost  growth  among  these 
47  major  programs  is  illustrated  in  Figure  11-6.  Note 
that  slightly  more  than  two-fifths  of  the  118  percent 
cost  growth  can  be  attributed  to  quantity  and 
schedule  changes.  Cost  growth  due  to  estimating 
changes  contributes  another  one-fifth. 

An  additional  consequence  of  our  current  tech¬ 
niques  for  dealing  with  uncertainties  is  our  lack  of 
credibility  both  in  the  view  of  the  Congress  and  also 
in  the  eyes  of  many  people  in  the  industrial  sector. 
This  consequence  is  a  direct  result  of  our  apparent 
inability  to  stabilize  our  programs  and  stem  the  tide 
of  cost  growth.  The  Deputy  Secretary  of  Defense  is 
particularly  concerned  with  this  lack  of  credibility 
because  it  not  only  encourages  the  Congress  to  take 
a  direct  role  in  the  management  of  our  programs  but 
also  discourages  much-needed  capital  investment  by 
the  industrial  sector. 

The  uncertainties  which  are  not  within  our  grasp 
are  primarily  of  a  technical  origin.  They  arise,  in 
part,  from  the  need  to  insert  new  technology  as  fast 
as  possible  to  offset  the  numerical  advantages  of  the 
Soviet  Union  and  the  Warsaw  Pact.  The  following 
four  actions  are  designed  specifically  to  help  cope 
with  technical  uncertainties: 

2.  Increase  use  of  Pre-Planned  Product  Im¬ 
provement  (PI). 

11.  Budget  for  Technological  Risk. 

12.  Provide  Front-End  Funding  for  Test  Hard¬ 
ware. 
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Figure  11-6 
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15.  Enhance  Funding  Flexibility. 

Pre-planned  product  improvement  (Action  2)  re¬ 
duces  technical  risk  and  increases  the  likelihood  of 
meeting  the  initial  operational  capability  (IOC)  date 
by  allowing  the  weapon  system  to  be  fielded  without 
the  ultimate  state-of-the-art  technology  but  with  pro¬ 
visions  for  incorporating  the  higher  technology  at  a 
later  date  when  it  has  matured.  There  is,  of  course, 
an  ancillary  benefit  in  that  a  weapon  system  designed 
in  anticipation  of  product  improvements  may  provide 
a  low-cost  alternative  to  the  development  of  an  en¬ 
tirely  new  weapon  system  to  counter  a  future  threat. 

To  be  effective,  pre-planned  product  improve¬ 
ment  must  be  an  integral]  part  of  the  acquisition 
strategy;  this  requires  that  the  planning  begin  early 
in  the  acquisition  cycle  and  that  funds  be  set  aside  to 
develop  the  new  technology.  Note  that,  while  Pff  is 
often  thought  of  as  a  technique  for  upgrading  the 
performance  of  a  system,  it  may  also  be  effectively 
used  to  upgrade  the  supportability  and  maintainabil¬ 
ity.  Needless  to  say,  the  existence  of  a  P3I  program 
should  not  be  used  as  an  excuse  for  allowing  fielding 
of  a  system  which  fails  to  meet  its  initial  performance 
and  readiness  goals. 


Action  11  recognizes  the  traditional  difficulty  we 
have  had  in  justifying  and  protecting  funds  (a  type  of 
management  reserve)  for  unanticipated  technical  dif¬ 
ficulties.  In  recent  years  both  the  Army  and  the  Air 
Force  have  developed  scientifically  sound  techniques 
for  estimating  the  risk  of  a  program  and  the  contin¬ 
gency  funds  that  should  be  set  aside  to  cope  with  un¬ 
anticipated  difficulties.  These  techniques  consider 
each  element  of  the  program  (e.g.,  the  elements  in 
the  work  breakdown  structure),  assign  a  risk  to  each 
element,  and  use  mathematical  methods  to  combine 
the  data  and  develop  a  measure  of  the  risk  for  the 
whole  program. 

In  this  context,  Action  11  requires  the  services  to 
increase  their  efforts  to  quantify  risk  and  to  expand 
the  use  of  budgeted  funds  to  deal  with  uncertainty. 
Needless  to  say,  there  is  an  implied  pledge  by  the 
DOD  that  effectively  justified  reserves  will  not  be  the 
first  targets  for  budget  cutting  and  redistribution  ex¬ 
ercises. 

The  primary  objective  of  Action  12  is  to  reduce  the 
length  of  the  acquisition  cycle  while  holding  the  risk 
at  an  acceptable  level  by  providing  additional  test 
hardware  so  that  developmental  and  operational 
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tests  can  be  conducted  concurrently.  Needless  to  say, 
this  requires  that  the  test  hardware  be  built  early  in 
the  program,  and  that  the  program  manager  resist 
the  temptation  (when  faced  with  other  pressing 
needs)  to  discount  the  importance  of  testing.  Action 
12  also  stresses  the  importance  of  combined  environ¬ 
mental  tests,  and  the  importance  of  the  test-fix-test 
process  (starting  early  in  the  program). 

Action  15  recognizes  that  in  some  cases  it  is  de¬ 
sirable  to  convert  production  moneys  into  RDT&E 
funds;  a  case  in  point  is  a  program  which  is  slated  to 
enter  production  but  has  been  delayed  due  to  techni¬ 
cal  difficulties.  Although  the  DOD  has  statutory 
authority  to  reprogram  a  total  of  $750  million  a  year 
between  authorizations,  the  institutional  im¬ 
pediments  (review  by  OMB  and  by  congressional 
oversight  committees)  virtually  prevent  these  repro¬ 
gramming  actions.  DOD  is  currently  seeking  relief 
from  these  impediments. 

In  addition  to  technical  difficulties,  a  key  source  of 
program  turbulence  is  the  lack  of  discipline  with 
which  we  plan  for  the  out  years.  The  following  four 
actions  deal  directly  with  planning: 

25.  Submit  the  MENS  with  the  Service  POM. 

29.  Integrate  the  DSARC  and  PPBS  Processes. 

4.  Increase  Program  Stability. 

7.  Use  Economical  Production  Rates. 

Mr.  Carlucci  put  his  finger  on  a  key  element  of  the 
problem  in  the  following  quotation  from  his 
27  March  1981  memorandum  on  management  of  the 
PPBS: 

I  agree  with  the  consensus  that  we  must 
both  improve  strategic  planning  in  the 
early  planning  phase  of  the  PPBS  cycle 
and  strengthen  long-range  planning 
throughout  the  other  phases  of  the 
PPBS.  This  calls  for  a  more  disciplined 
planning  process  that  will  provide  the 
framework,  the  goals  and  objectives,  the 
appropriate  military  strategies,  and  the 
risks  associated  with  the  optimum  alloca¬ 
tion  of  available  resources. 

In  this  context,  a  key  feature  of  the  27  March  1981 
memorandum  is  the  redefinition  of  the  membership 
and  role  of  the  Defense  Resources  Board  (DRB).  The 
DRB  is  chaired  by  the  Deputy  Secretary  of  Defense 
and  has  been  expanded  to  include  17  regular 
members,  including  all  the  members  of  the  DSARC. 
Its  charter  includes: 

—Reviewing  proposed  planning  guidance; 
—Managing  the  program  and  budget  review  process; 
—Advising  the  Secretary  of  Defense  on  policy,  plan¬ 
ning,  program  and  budget  issues  and  proposed  deci¬ 
sions; 


—Evaluating  and  reviewing  high  priority  programs 
on  a  regular  basis; 

—Assuring  that  major  acquisition  systems  are  more 
closely  aligned  to  the  PPBS. 

In  addition,  the  27  March  1981  memorandum 
makes  other  specific  changes  to  the  PPBS  process. 
For  example,  it  required  that  the  documentation  for 
the  FY  83  POM  be  cut  by  50  percent  and  required 
that  the  comptroller  slash  the  huge  amount  of  paper¬ 
work  required  for  the  zero  base  budgeting  (ZBB) 
process.  More  importantly,  the  memorandum 
charged  key  OSD  offices  with  developing  plans  for 
significantly  improving  the  OSD  programming  proc¬ 
ess.  Thus,  in  a  sense,  the  four  acquisition  improve¬ 
ment  actions  are  but  a  small  part  of  a  much  larger  ac¬ 
tivity  within  the  DOD. 

Actions  25  and  29  are  aimed  at  bridging  the  gap 
between  the  DSARC  process  and  the  PPBS  process. 
Specifically,  these  actions  require  that,  at  each  of  the 
first  three  decision  points  in  a  program  (Program  Ini¬ 
tiation,  Requirement  Validation,  and  Program  Go- 
Ahead),  the  service  guarantee  that  adequate  funds 
are  budgeted  to  carry  the  program  to  the  next  mile¬ 
stone.  The  requirement  to  submit  the  MENS  with  the 
POM  was  described  earlier.  In  the  case  of  the  Re¬ 
quirement  Validation  and  Program  Go-Ahead  mile¬ 
stones,  the  service  secretary  will  assure  the  DSARC 
that  sufficient  resources  are  provided  in  the  Five 
Year  Defense  Plan  and  the  Extended  Planning 
Annex  (or  can  be  programmed)  to  execute  the  pro¬ 
gram  as  recommended. 

Action  4  requires  that  the  Secretary  of  Defense, 
OSD,  and  the  services  fully  fund  both  the  R&D  and 
the  procurement  of  major  systems  at  levels  necessary 
to  protect  the  acquisition  strategy  established  when 
the  program  was  baselined.  Programs  will  be  re¬ 
viewed  for  compliance  with  this  requirement  during 
program  and  budget  review  by  the  Defense  Re¬ 
sources  Board. 

So  far  in  this  section,  attention  has  been  focused 
on  those  actions  which  deal  with  technological  risk 
and  with  planning.  The  following  six  actions  are  pri¬ 
marily  aimed  at  improving  costing  and  execution  of 
weapon  system  programs. 

6.  Budget  to  Most  Likely  Cost. 

8.  Assure  Appropriate  Contract  Type. 

20.  Improve  the  Source  Selection  Process. 

22.  Provide  More  Appropriate  Design-to-Cost 
Goals. 

18.  Budget  Weapons  Systems  for  Inflation. 

19.  Forecast  Business  Base  Conditions  at  Major 
Defense  Plants. 

It  is,  of  course,  realized  that  our  cost  estimating 
and  budgeting  processes  have  significant  room  for 
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improvement.  At  the  same  time,  it  is  recognized  that 
the  problem  is  compounded  as  we  struggle  to  fit 
more  and  more  programs  within  the  confines  of  a 
fixed  budget.  In  response  to  this  constraint,  we  often 
feel  compelled  to  accept  intentionally  low  initial  cost 
estimates;  this  process,  usually  referred  to  as  “buying 
in,”  frequently  leads  to  apparent  cost  overruns  an 
criticism  of  our  management  abilities. 

The  thrust  here  is  twofold.  On  the  one  hand,  we  in 
the  federal  government  are  being  required  to  take  a 
much  more  vigorous  role  in  cost  estimating.  We  are 
asked  to  pay  particular  attention  to  predictable  cost 
increases  due  to  risk.  And  we  are  asked  to  develop 
more  reliable  estimates  of  cost  and  to  stop  relying  so 
heavily  on  contractor  estimates.  On  the  other  hand, 
the  contractor  is  also  required  to  give  us  more  accu¬ 
rate  cost  estimates.  To  this  end,  a  series  of  specific 
actions  has  been  identified:  (1)  Improve  the  source 
selection  process  to  place  added  emphasis  on  past 
performance,  schedule  realism,  facilitization  plans, 
and  cost  credibility;  (2)  Provide  contractual  incen¬ 
tives  to  encourage  good  performance  with  respect  to 
cost  goals;  (3)  Make  design-to-cost  a  more  viable  tool 
by  delaying  fee  awards  until  after  the  initial  items 
have  come  off  the  production  line  and  real  produc¬ 
tion  costs  can  be  determined. 

The  objective  of  these  actions  is  to  reduce  the 
number  of  overruns  and  to  reduce  the  number  of 
times  that  contractors  feel  they  must  “buy-in”  in 
order  to  compete.  At  the  same  time,  DOD  recognizes 
that  there  are  some  other  actions  it  can  take  to  make 
your  job  easier.  One  of  these  is  helping  the  program 
manager  cope  with  unrealistic  inflation  rates.  The 
difficulty  with  this  initiative  is,  of  course,  the  political 
implications.  Effective  techniques  are  being  studied. 

The  last  action  in  this  group  reflects  the  fact  that 
fluctuations  in  DOD  and  non-DOD  work  tend  to  dis¬ 
tort  business  base  projections  and  sometimes  seri¬ 
ously  increase  overhead  costs.  To  offset  this  situa¬ 
tion,  the  OSD  Cost  Analysis  Improvement  Group 
(CAIG)  will  collect  data  and  assist  in  improving 
forecasting. 

Improve  Industrial  Productivity 

The  third  major  thrust  of  the  acquisition  improve¬ 
ment  actions  is  to  improve  industrial  productivity. 
Note  at  the  outset,  however,  that  this  is  a  small  piece 
of  a  much  larger  activity  in  the  Department  of  De¬ 
fense.  The  Department  of  Defense  has  prepared  a 
plan,  entitled  “Action  Plan  for  Improvement  on  In¬ 
dustrial  Responsiveness.”  which  is  designed  to  signif¬ 
icantly  strengthen  the  industrial  base.  A  tri-service 
committee  has  been  established  to  implement 


numerous  action  items  within  this  plan.  The  stated 
objectives  of  this  plan  are  to: 

—Enable  American  industry  to  undertake  a  program 
of  capital  investment; 

—Improve  American  self-sufficiency  in  the  area  of 
critical  raw  materials; 

—Ensure  sufficient  skilled  manpower  exists  to  meet 
the  demand  of  American  industry; 

—Improve  the  quality  of  American  workmanship  and 
products; 

—Impose  stability  on  military  procurement  programs 
and  resource  demands; 

—Make  the  defense  market  an  attractive  place  for 
Amerian  industry  to  do  business; 

—Make  military  equipment  designs  compatible  with 
commercial  industrial  production  capabilities; 
—Create  an  industrial  base  that  is  responsive  to 
mobilization  needs. 

The  increase  in  lead  times  illustrated  in  Fig¬ 
ure  11-7  is  just  one  indicator  of  the  problems  which 
the  industrial  base  is  facing.  Note  that  the  data  in  this 
chart  reflect  the  mid-1980  time  frame  and  that  in  re¬ 
cent  months  lead  times  have  improved  markedly. 
Nevertheless  the  data  are  significant  reminders  of  the 
inability  of  the  industry  to  cope  with  fluctuations  in 
demand. 

The  fundamental  thrust  of  the  actions  in  this  area 
is  to  create  a  favorable  environment  for  capital  in¬ 
vestment  by  the  industries.  It  is  firmly  believed  that, 
with  appropriate  incentives,  the  industry  will  go  a 
long  way  toward  curing  its  own  ills.  The  following  ac¬ 
tions  address  this  area: 

5.  Encourage  Capital  Investment  to  Enhance 
Productivity. 

3.  Implement  Multiyear  Procurement. 

32.  Increase  Competition. 

Action  5  contains  more  than  a  half  dozen  specific 
actions  which  are  designed  to  stimulate  capital  in¬ 
vestment  and  ease  cash  flow  problems.  Some  of 
these  actions  already  have  been  accomlished;  for  ex¬ 
ample,  progress  payments  have  been  accelerated, 
and  the  new  tax  law  contains  more  liberal  capital 
equipment  depreciation  provisions.  Other  actions, 
such  as  the  initiative  to  repeal  the  Vinson-Trammell 
Act,  are  still  in  progress. 

Action  5  also  encourages  the  services  to  place  in¬ 
creased  emphasis  on  their  manufacturing  technology 
programs.  These  programs  are,  of  course,  already 
strongly  supported  by  the  services.  It  is  worth  noting 
in  passing  that  it  is  entirely  appropriate  to  pursue  a 
manufacturing  technology  program  in  parallel  with  a 
RDT&E  program. 

Multiyear  procurement,  used  when  appropriate, 
has  two  advantages.  On  the  one  hand,  it  creates  a 
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Figure  11-7 
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secure  climate  in  which  contractors  will  more  readily 
make  capital  equipment  investments.  On  the  other 
hand,  it  permits  the  contractor  to  buy  materials  and 
components  in  more  economic  lot  sizes;  a  single  buy 
can,  for  example,  provide  the  requirements  for  an 
entire  5-year  contract.  It  has  been  estimated  that  10 
to  1 5  percent  can  be  saved  through  purchases  of  this 
sort. 

The  principal  unresolved  issue  with  respect  to 
multiyear  procurement  is  budgeting  for  the  cancella¬ 
tion  ceiling.  The  requirement  to  budget  for  cancella¬ 
tion  ceilings  would  tie  up  substantial  fractions  on  the 
total  obligation  authority  (TOA)  and  would  thus 
make  multiyear  procurement  a  less  attractive  option 
in  most  instances. 

Mr.  Carlucci  added  Action  32,  Competition,  to  the 
original  31  actions  on  27  July.  The  primary  objec¬ 
tives  of  competition  are  to  stimulate  innovation  (both 
in  design  and  in  manufacturing  practice)  and  to  stim¬ 
ulate  investment.  Provided  the  competition  is  effec¬ 
tive  (and  not  a  pro  forma  square-filling  exercise),  the 
program  manager  potentially  can  realize  both  cost 
savings  and  risk  reduction.  At  the  same  time,  the  in¬ 
dustrial  base  is  strengthened  through  investment  in 
technology  and  in  productivity.  Needless  to  say,  in¬ 
discriminate  enforcement  of  competition  leads  to 
senseless  expenditure  of  government  and  industrial 
funds.  Thus  the  program  manager  must  evaluate  his 
opportunities  for  competition  in  terms  of  cost,  poten¬ 
tial  for  cost  reduction,  and  risk  reduction. 

Increase  Readiness 

The  fourth  thrust  of  the  actions  to  improve  defense 
acquisition  is  to  improve  the  readiness  of  systems  in 
the  field.  Concerns  in  this  area  include  the  delayed 
entry  of  systems  into  the  field,  the  delayed  support  of 
systems  in  the  field,  and  the  high  cost  of  ownership 
once  the  systems  have  been  fielded.  The  costs  of 


ownership  include  the  full  spectrum  of  operational, 
maintenance,  and  support  costs. 

The  central  theme  running  through  all  five  of  the 
actions  dealing  with  readiness  was  explictly  stated  in 
Action  1,  Management  Principles: 

Improved  readiness  is  a  primary  objective 
of  the  acquisition  process,  of  comparable 
importance  to  reduced  unit  cost  or  re¬ 
duced  acquisition  time.  Resources  to 
achieve  readiness  will  receive  the  same 
emphasis  as  those  required  to  achieve 
schedule  or  performance  objectives. 

The  five  actions  listed  below  single-mindedly  echo 
this  theme: 

9.  Improve  System  Support  and  Readiness. 

31.  Improve  Reliability  and  Support  for  Short¬ 
ened  Acquisition  Cycles. 

21.  Develop  and  Use  Standard  Operational  and 
Support  Systems. 

16.  Provide  Contractor  Incentives  to  Improve 
Reliability  and  Support. 

30.  Increase  Program  Manager  Visibility  of  Sup¬ 
port  Resources. 

It  has,  of  course,  been  recognized  for  many  years 
that  a  weapon  system  can  be  designed  to  incorporate 
features  which  facilitate  its  supportability  and  in¬ 
crease  its  readiness.  A  case  in  point  is  the  F-18  air¬ 
craft.  Moreover,  since  the  vast  majority  of  weapon 
system  costs  are  determined  by  decisions  that  are 
made  very  early  in  the  program,  it  is  vitally  important 
to  consider  logistics  at  the  earliest  possible  moment 
in  the  program. 

For  those  reasons,  Secretary  Weinberger  and  Dep¬ 
uty  Secretary  Carlucci  felt  that  it  was  necessary  to 
challenge  the  program  manager  in  the  stiffest  possi¬ 
ble  terms.  The  reader  is  encouraged  to  study  Actions 
9  and  31  particularly. 
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(1)  The  program  manager  must  define  the  readi¬ 
ness  objectives  for  the  system  as  early  as  possible  and 
must  be  prepared  to  defend  these  objectives  at  the 
Requirement  Validation  milestone  review.  The  readi¬ 
ness  objectives  of  concern  at  this  point  go  far  beyond 
the  normal  items  such  as  mean  time  between  failure 
(MTBF),  and  address  real  system  capabilities  such  as 
the  ability  to  generate  sorties. 

(2)  The  program  manager  must  design  reliability 
and  supportability  into  his  weapon  system  and  explic¬ 
itly  earmark  resources  early  in  the  weapon  system 
program  to  support  these  design  efforts.  The  ulti¬ 
mate  objective  is  to  conserve  the  funds  needed  to 
support  the  system  after  it  has  been  fielded. 

(3)  Particularly  in  the  case  of  “fast-track”  pro¬ 
grams,  the  program  manager  must  examine  the  feasi¬ 
bility  and  potential  payoff  of  concurrent  development 
and  testing  phases. 

(4)  The  program  manager  must  begin  the  iterative 
testing-design  phases  early  in  the  program  so  that 
the  system  can  mature  in  an  orderly  manner. 

(5)  The  services  are  encouraged  to  target  selected 
force  elements  for  major  upgrades,  which  will  make 
them  significantly  less  dependent  upon  logistic  tails. 
This,  of  course,  entails  even  more  RDT&E  effort. 

Action  21  echoes  the  well-known  requirement  that 
standard  operational  and  support  systems  be  used. 
However,  the  emphasis  of  this  action  is  on  RDT&E 
of  new  standard  systems  and  the  associated  technol¬ 
ogy.  Items  of  particular  interest  in  this  group  include 
both  avionics  equipment  and  test  systems. 

Action  16  specifically  recognizes  the  validity  of  the 
use  of  contractual  incentives  as  a  technique  for  stim¬ 
ulating  the  contractor  to  pay  more  attention  to  relia¬ 
bility,  maintainability,  supportability,  etc.  The  pro¬ 
gram  manager  should  include  logistics  considera¬ 
tions  among  the  source  selection  criteria,  write  spe¬ 
cific  incentives  into  the  contract  itself,  and  consider 
the  use  (where  appropriate)  of  instruments  such  as 
reliability  improvement  warranties  (RIWs).  In  the 
F-16  program,  for  example,  nine  separate  items  are 
covered  by  RIWs,  and  two  items  have  mean-time- 
between-failure  guarantees. 

One  last  item  deserves  special  mention:  Action  30 
recognizes  that,  because  of  the  nature  of  the  PPBS 
process,  the  program  manager  can  sometimes  be  un¬ 
aware  of  logistics  decisions  that  directly  impact  the 
support  of  the  system  he  is  developing.  In  an  attempt 
to  ease  this  difficulty,  both  the  OSD  and  the  services 
are  developing  and  implementing  procedures  which 
will  give  the  program  manager  more  visibility  into  re¬ 
source  decisions  relating  to  his  support  assets. 


Reduce  Administrative  Overhead  Cost 
and  Time 

The  fifth  and  final  thrust  of  the  actions  to  improve 
defense  acquisition  is  to  attack  those  legal  require¬ 
ments  and  administrative  arrangements  which  add 
time  and  cost  to  the  acquisition  of  weapon  systems. 
The  concerns  include  overmanagement  at  all  levels 
of  the  government,  the  overall  impact  of  government 
constraints,  both  administrative  and  legislative,  and 
the  impact  of  various  outdated  laws,  directives,  in¬ 
structions,  and  regulations. 

The  following  three  actions  provide  an  umbrella 
for  a  series  of  specific  initiatives: 

13.  Reduce  Governmental  Legislation  Related 
to  Acquisition. 

14.  Reduce  the  Number  of  DOD  Directives. 

10.  Reduce  the  Administrative  Cost  and  Time  to 
Procure  Items. 

Action  13  is  designed  to  reduce  the  impact  of  ex¬ 
cessively  burdensome  legislative  programs.  At  the 
outset,  it  must  be  admitted  that  each  legislative  ac¬ 
tion  that  affects  the  acquisition  process  has  its  own 
appropriate  goal.  However,  it  has  been  possible  to 
identify  some  legislative  requirements  whose  goals 
are  no  longer  particularly  appropriate,  and  to  identify 
some  other  legislative  requirements  whose  impact  on 
the  defense  acquisition  process  is  much  more  severe 
than  the  benefits  accrued  as  the  result  of  the  legisla¬ 
tive  action.  It  has  therefore  been  possible  to  identify 
several  target  legislative  measures.  For  example,  in 
the  view  of  many  people,  the  statutory  limitation  on 
fees  for  cost-plus-fixed-fee  contracts  is  outmoded  and 
should  he  eliminated. 

In  some  cases,  we  simply  “do  it  to  ourselves.”  A 
classic  example  is  the  growth  of  DOD  directives  and 
instructions.  It  has  been  10  years  since  the  last  purge 
of  directives  and  instructions,  which  reduced  the 
number  of  such  documents  from  140  to  69.  Now, 
with  the  number  of  directives  and  instructions  again 
approaching  140,  the  process  has  begun  once  again 
by  the  direction  of  Mr.  Carlucci.  In  addition,  in  an  ef¬ 
fort  to  hold  down  the  number  of  directives  and  in¬ 
structions  in  the  future,  the  Defense  Acquisition  Ex¬ 
ecutive  has  been  designated  as  the  sole  issuer  of  fu¬ 
ture  DOD  directives  related  to  acquisition. 

Action  10  deals  with  raising  the  thresholds  for  vari¬ 
ous  administrative  actions.  Most  of  these  thresholds 
were  established  many  years  ago  and  have  not  kept 
pace  with  inflation.  As  a  specific  case  in  point,  Action 
10  seeks  to  raise  the  reprogramming  thresholds  from 
$2  million  to  $10  million  for  RDT&E  appropriations 
and  from  $5  million  to  $25  million  for  procurement 
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Figure  11-8 
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appropriations.  An  interesting  innovation  in  the  cur¬ 
rent  action  is  the  suggestion  to  tie  the  new  thresholds 
to  inflation.  Action  10  also  seeks  to  relieve  the 
amount  of  paperwork  and  administrative  overhead. 
For  example,  it  encourages  the  use  of  Class  deter¬ 
minations  and  findings  (D&Fs),  an  action  that  is  ex¬ 
plicitly  permitted  by  current  directives  but  often 
frowned  upon  in  practice. 

Conclusion 

This  brings  us  to  the  conclusion;  as  we  reflect  back 
across  the  specific  actions,  we  must  keep  in  mind 
that  they  cannot  be  applied  blindly  to  all  programs. 
Indeed,  by  their  very  nature,  these  actions  require 
that  the  program  manager  make  trade-offs— make 
decisions  among  the  many  opportunities  and  chal¬ 
lenges  offered  by  these  actions. 

Figure  11-8  gives,  in  summary  form,  a  status  report 
on  the  implementation  of  the  32  actions  to  improve 
defense  acquisition.  With  respect  to  the  data  dis¬ 
played  here,  two  observations  are  important.  First, 
11  of  the  Actions  (or  parts  of  them)  have  been  ac¬ 
complished;  thus,  significant  steps  have  already  been 
taken  toward  improving  the  acquisition  process.  Sec¬ 
ond,  17  of  the  actions  are  now  in  your  court;  in  most 
cases,  you— the  program  manager— are  in  the  best 
position  to  determine  whether  each  of  these  17  ac¬ 
tions  is  appropriate  for  your  program.  You— the  pro¬ 
gram  manager— have  the  opportunity  to  contribute 


significantly  to  the  overall  improvement  of  the  ac¬ 
quisition  process. 

There  are  many  implications  both  for  the  services 
and  for  the  program  managers.  Perhaps  most  impor¬ 
tant  as  far  as  the  services  are  concerned  is  the  expec¬ 
tation  that  these  actions  will  be  endorsed  by  the  serv¬ 
ices  and  that  they  will  be  passed  down  the  chain  of 
command  to  the  program  managers.  There  is  the 
firm  expectation  that  responsibility,  authority,  and 
accountability  will  be  delegated  to  a  much  greater  de¬ 
gree  than  is  done  today.  There  is  the  further  expecta¬ 
tion  that  the  services  will  reduce  the  number  of  re¬ 
porting  and  reviewing  requirements,  thus  freeing  the 
program  managers  to  do  other  tasks  implied  by  the 
acquisition  improvement  actions.  Indeed,  although 
the  DOD  can  take  the  lead  and  can  make  the  pro¬ 
gram  manager’s  life  a  little  bit  easier,  the  Department 
of  Defense  must  rely  on  the  services  to  make  the  big 
impact  on  the  environment  within  which  the  program 
manager  operates. 

In  addition,  Mr.  Carlucci  has  placed  a  great  deal  of 
emphasis  upon  program  stability,  charged  the  serv¬ 
ices  to  develop  realistic  plans,  and  insisted  that  these 
plans  be  considered  as  contracts  between  the  serv¬ 
ices  and  the  Department  of  Defense. 

The  program  manager,  for  his  part,  has  a  lot  of 
things  to  think  about.  At  the  start,  he  is  encouraged 
to  tailor  his  acquisition  strategy,  and  to  put  money 
“up-front”  with  the  expectation  that  money  spent  up- 
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front  will  reduce  the  total  cost  of  the  acquisition.  The 
program  manager  is  asked  to  spend  more  time  with 
realistic  costing,  and  to  encourage  the  contractors  to 
do  the  same.  The  program  manager  should  investi¬ 
gate  the  use  of  multiyear  procurements  to  lend  stabil¬ 
ity  to  his  programs.  The  program  manager  should  in¬ 
vestigate  the  use  of  a  wide  variety  of  incentives  both 
to  encourage  the  strengthening  of  the  industrial  base 
and  to  encourage  quality  performance  on  the  part  of 
contractors.  The  program  manager  is  encouraged  to 
budget  for  risk,  and  told  tacitly  that  these  funds  will 
not  be  held  in  jeopardy.  The  program  manager  is 
asked  to  examine  the  evolutionary  introduction  of 
new  technology.  And  finally,  the  program  manager  is 
asked  to  put  much  more  emphasis  on  integrated  lo¬ 
gistics  support  throughout  the  acquisition  process. 
To  help  the  program  manager  in  these  many  tasks, 
he  is  promised  increased  financial  flexibility  in  deal¬ 
ing  with  the  uncertainties  he  is  certain  to  encounter. 
He  is  promised  that  the  load  of  reporting  and  review¬ 
ing  and  briefing  will  be  reduced.  And  he  is  promised 
that  the  burdensome  load  of  legislative  and  regula¬ 
tory  requirements  will  be  reduced. 

In  some  respects  the  Department  of  Defense  Ac¬ 
quisition  Improvement  has  created  a  new  program 
management  environment.  One  of  the  most  obvious 
characteristics  of  this  new  environment  is  the  insis¬ 
tence  in  many  of  the  actions  that  additional  funds  be 
spent  “up-front,”  with  the  expectation  that  the  bene¬ 
fits  will  be  reaped  later  in  the  life  cycle  of  the  weapon 
system.  Many  examples  come  to  mind:  front-end 
funding  for  test  hardware,  pre-planned  product  im¬ 
provement,  economic  production  rates,  just  to  name 
a  few.  Even  with  the  currently  projected  FY  82  DOD 
budget,  there  is  no  way  that  all  the  implied  fiscal  re¬ 
quirements  can  be  met.  The  implication  is  clear: 
High-priority  programs  will  receive  strong  support, 
and  low-priority  programs  will  be  cut.  The  measure 
of  our  management  ability  will  be  our  ability  to  make 
the  tough  decisions  this  implies. 

As  we  try  to  characterize  this  new  environment  fur¬ 
ther,  several  key  words  come  to  mind. 

The  program  manager  will  have  greater  authority 
and  responsibility  in  the  new  environment,  and  will 
have  more  flexibility  to  deal  with  the  uncertainties  he 
is  certain  to  encounter.  As  the  same  time,  a  great 
deal  is  expected  of  the  program  manager  and  he  will 
be  held  accountable  for  his  actions.  Indeed,  his 
credibility  and  the  credibility  of  his  program  will  be 
gauged  by  how  well  he  makes  his  decisions. 

Credibility  is  crucially  important  in  the  larger  con¬ 
text  as  well.  It  is  vitally  important  that  we  in  the  DOD 
reestablish  our  credibility  in  the  view  of  Congress 
and  in  the  view  of  our  industrial  counterparts.  To  do 


this,  we  must  demonstrate  both  the  commitment  and 
the  discipline  to  manage  our  programs  well.  We  must 
erase  the  image  that  DOD  programs  are  out  of  con¬ 
trol. 

There  is  a  tremendous  amount  of  excitement  about 
the  32  actions.  This  excitement  is  engendered  in  part 
by  the  fact  that  the  services  have  been  involved  in  the 
development  of  the  actions  from  the  first  day.  Thus, 
even  the  generation  of  the  actions  illustrates  the  par¬ 
ticipative  management  that  Mr.  Carlucci  is  seeking. 
The  excitement  also  stems  from  the  realization  that, 
for  the  first  time  in  many  years,  some  real  changes  in 
the  acquisition  process  may  be  possible.  And,  the  ex¬ 
citement  stems  from  the  realization  that  the  Depart¬ 
ment  of  Defense,  beginning  with  Secretary 
Weinberger,  Deputy  Secretary  Carlucci,  and  others, 
is  absolutely  committed  to  the  implementation  of 
these  actions.  And  finally,  there  is  the  urgency  I 
referred  to  in  the  introduction  to  this  paper.  As 
noted  earlier,  it  will  be  necessary  to  have  a  large  infu¬ 
sion  of  money  right  now  in  order  to  accomplish  many 
of  these  actions.  The  FY  82  budget  provides  such  a 
large  infusion  of  money.  Inasmuch  as  this  could  pos¬ 
sibly  be  a  singular  event  in  time,  it  is  imperative  that 
these  actions  be  pursued  with  utmost  vigor  and 
urgency  at  this  time.  The  net  result  will  be  significant 
enhancement  of  our  preparedness. 

Footnotes 

1.  Shortly  before  the  Joint  Commander  signed  this  guide,  the  Deputy 
Secretary  of  Defense,  Frank  C.  Carlucci  signed  DOD  Directive  5000.1  on 
29  March  1982.  Also,  on  12  April  1982,  the  Under  Secretary  of  Defense, 
Research  and  Engineering,  Richard  D.  DeLauer,  promulgated  by 
memorandum  major  defense  system  acquisition  program  documentation 
format.  Because  of  the  close  proximity  of  these  events,  the  policy  and  re¬ 
quirements  of  these  documents  may  not  be  fully  included  in  this  guide. 
Accordingly,  the  reader  should  seek  additional  guidance  from  these 
source  documents. 
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APPENDIX  A 

Memorandum  of 
Agreement  on  the 
Management  of 
Multi-Service 
Sgstems/Programs/ 
Projects1 


1.  Purpose: 

This  Memorandum  establishes  policies  for  im¬ 
plementing  multi-service  systems,  program/project- 
management  in  accordance  with  DOD  Directive 
5000.1,  “Acquisition  of  Major  -Defense  Systems,” 
13  July  1971.  It  is  the  basic  policy  document  for  man¬ 
agement  of  multi-service  systems,  programs  and  pro¬ 
jects,  and  the  framework  within  which,  like  DOD 
Directive  5000.1,  acquisition  management  pro¬ 
cedures  must  operate. 

2.  Policy: 

The  Service  designated  as  the  Executive  Agent 
shall  have  the  authority  to  manage  the  program/pro¬ 
ject-  under  the  policies  and  procedures  used  by  that 
Service.  The  Program/Project  Manager,  the  Pro¬ 
gram/Project  Management  Office,  and,  in  turn,  the 
functional  elements  of  each  Participating  Service  will 
operate  under  the  policies,  procedures,  data,  stand¬ 
ards,  specifications,  criteria  and  financial  accounting 
of  the  Executive  Service.  Exceptions,  as  a  general 
rule,  will  be  limited  to  those  where  prior  mutual 
agreement  exists  or  those  essential  to  satisfy  the 
substantive  needs  of  the  Participating  Services.  This 
may  require  the  Participating  Services  to  accept  cer¬ 
tain  deviations  from  their  policies  and  procedures  so 
as  to  accommodate  the  assumption  of  full  program/ 
project-  responsibility  by  the  Executive  Service. 
Demands  for  formal  reporting  as  well  as  non¬ 
recurring  needs  for  information  will  be  kept  to  a 
minimum. 

3.  Responsibilities 

a.  The  Executive  Service  will: 

(1)  Assign  the  Program/Project- Manager. 

(2)  Establish  an  official  manning  document 
for  the  Program/Project  Management  Office  which 


will  incorporate  the  positions  to  be  occupied  by 
representatives  of  the  Participating  Services,  e.g., 
Department  of  the  Army  Table  of  Distribution  and 
Allowances  (TDA)/Department  of  the  Navy  Man¬ 
power  Listing/Department  of  the  Air  Force  Unit 
Detail  Listing  (UDL).  The  manning  document  devel¬ 
oped  from  the  Joint  Operating  Procedure  on  Staffing 
will  also  designate  a  key  position  for  occupancy  by 
the  Senior  Representative  from  each  of  the  Par¬ 
ticipating  Services. 

(3)  Staff  the  Program/Project-  Management 
Office  with  the  exception  of  the  positions  identified 
on  the  manning  document  for  occupancy  by  person¬ 
nel  to  be  provided  by  the  Participating  Services.  Inte¬ 
grate  the  Participating  Service  personnel  into  the 
Program/Project-  Management  Office. 

(4)  Be  responsible  for  the  administrative 
support  of  the  Program/Project-  Management  Office. 

(5)  Delineate  functional  tasks  to  be  ac¬ 
complished  by  all  participants. 

b.  The  Participating  Services  will: 

(1)  Assign  personnel  to  the  Program/Project- 
Management  Office  to  fill  identified  positions  on  the 
manning  document  and  to  assist  the  Program/Pro¬ 
ject-Manager  in  satisfying  the  requirements  of  all  par¬ 
ticipants.  Numbers,  qualifications  and  specific  duty 
assignments  of  personnel  to  be  initially  provided  by 
each  Participating  Service  will  be  reflected  in  the 
Joint  Operating  Procedure. 

(2)  The  Senior  Representative  from  each  Par¬ 
ticipating  Service  will  be  assigned  to  a  key  position  in 
the  Program/Project-  Management  Office  and  report 
directly  to,  or  have  direct  access  to,  the  Pro¬ 
gram/Project-  Manager.  This  key  position  could  in¬ 
clude  assignment  as  Deputy  to  Program/Project- 
Manager.  He  will  function  as  his  Service’s  represen¬ 
tative,  \  ith  responsibilities  and  authorities  as  out- 
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lined  in  Paragraph  3.d  of  this  Agreement. 

(3)  Provide  travel  funds  and  support  neces¬ 
sary  for  the  accomplishment  of  the  responsibilities  of 
their  representatives  in  the  management  of  the  Pro¬ 
gram/Project: 

(4)  Accomplish  Program/Project  functional 
tasks  as  specifically  assigned  in  the  Charter,  in  the 
Master  Plan,  and  Joint  Operating  Procedures  (JOPs), 
or  as  requested  and  accepted  during  the  course  of 
the  Program/Project 

c.  The  Program/Project-  Manager  will: 

(1)  Satisfy  the  specific  operational,  support 
and  status  reporting  requirements  of  all  Participating 
Services. 

(2)  Be  responsible  for  planning,  controlling, 
coordinating,  organizing  and  directing  the  valida¬ 
tion,  development,  production,  procurement  and 
financial  management  of  the  Program/Project-. 

(3)  Review,  on  a  continuing  basis,  the  ade¬ 
quacy  of  resources  assigned. 

(4)  Assure  that  planning  is  accomplished  by 
the  organizations  responsible  for  the  complementary 
functions  of  logistics  support,  personnel  training, 
operational  testing,  military  construction  and  other 
facilities,  activation  or  deployment. 

(5)  Refer  to  the  appropriate  authority  those 
matters  that  require  decisions  by  higher  echelons. 
The  following  items  will  be  referred  to  appropriate 
authority: 

(a)  Deviations  from  the  established  Execu¬ 
tive  Service  policy  except  as  specifically  authorized 
by  the  Program/Project  documentation  (reference 
Paragraph  4  below). 

(b)  Increases  in  funding  of  the  Program/ 

Project: 

(c)  Changes  to  milestones  established  by 
higher  authority. 

(d)  Program/Project'  changes  degrading 
mission  performance  or  altering  operational  charac¬ 
teristics. 

d.  Participating  Service  Senior  Representative(s) 
within  the  Program/Project  Management  Office  will: 

(1)  Speak  for  his  parent  Service  in  all  matters 
subject-  to  the  limitations  prescribed  by  his  Service. 
Authority  of  the  Service  Senior  Representative  is 
subject-  to  the  same  limitations  listed  above  for  the 
Program/Project-  Manager. 

(2)  Refer  to  his  parent  Service  those  matters 
which  require  decisions  by  higher  echelons. 

4.  Documentation 

Management  for  particular  Multi-Service  Program/ 
Projects  shall  be  documented  by: 


a.  A  Multi-Service  Program/Project  Manager 
Charter.  The  responsible  Commander  in  the  Service 
having  principal  Program/Project-  management  re¬ 
sponsibility  will  cause  the  preparation,  negotiation 
and  issuance  of  a  jointly  approved  Charter  which  will 
identify  the  Program/Project'  Manager  and  establish 
his  management  office.  The  Charter  will  define  his 
mission  responsibility,  authority  and  major  functions, 
and  describe  his  relationships  with  other  organiza¬ 
tions  which  will  use  and/or  support  the  Program/Pro¬ 
ject-.  The  Charter  will  describe  and  assign  responsi¬ 
bility  for  satisfying  peculiar  management  require¬ 
ments  of  Participating  Services  which  are  to  be  met 
in  the  Program/Project,  and  will  be  jointly  approved 
for  the  Headquarters  of  each  involved  Service  by  per¬ 
sons  officially  appointed  to  approve  such  Charters. 

b.  A  Program/Project  Master  Plan.  This  is  the 
document  developed  and  issued  by  the  Program/Pro¬ 
ject-  Manager  which  shows  the  integrated  time- 
phased  tasks  and  resources  required  to  accomplish 
the  tasks  specified  in  the  approved  statement  of 
need/performance  requirements.  The  plan  will  be 
jointly  approved  for  each  involved  Service  by  persons 
officially  appointed  to  approved  such  plans. 

c.  Joint  Operating  Procedures  (JOPs).  These  will 
identify  and  describe  detailed  procedures  and  inter¬ 
actions  necessary  to  carry  out  significant  aspects  of 
the  Program/Project:  Subjects  for  JOPs  may  include 
Systems  Engineering,  Personnel  Staffing,  Reliability, 
Survivability,  Vulnerability,  Maintainability,  Produc¬ 
tion,  Management  Controls  and  Reporting  (including 
SAR),  Financial  Control,  Test  and  Evaluation,  Train¬ 
ing,  Logistics  Support,  Procurement  and  Deploy¬ 
ment.  The  JOPs  will  be  developed  and  negotiated  by 
the  Program/Project-  Manager  and  the  Senior  Repre¬ 
sentatives  from  the  Participating  Services.  An  op¬ 
tional  format  is  suggested  in  Attachment  1  to  this 
Agreement.  This  action  will  be  initiated  as  soon  as 
possible  and  accomplished  not  later  than  180  days 
after  promulgation  of  the  Multi-Service  Pro¬ 
gram/Project-  Manager  Charter.  Unresolved  issues 
will  be  reported  to  the  Charter  approving  authorities 
for  resolution. 

d.  Coordination/Communication.  Where  Partici¬ 
pating  Services  are  affected,  significant  program  ac¬ 
tion,  contractual,  or  otherwise,  will  not  be  taken  by 
the  Program/Project  Manager  without  full  consulta¬ 
tion  and  coordination  with  the  Participating  Services 
while  the  matter  is  still  in  the  planning  stage.  All  for¬ 
mal  communications  from  the  Program/Project-Man¬ 
agement  Office  to  higher  authority  in  the  Executive 
or  Participating  Services  will  be  signed  by  the  Pro¬ 
gram/Project-  Manager  or  his  designated  representa- 
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tive.  Substantive  change  to  the  Charter,  Master  Plan, 
or  JOPs  will  be  negotiated  with  affected  Participating 
Services  prior  to  issuance  as  an  approved  change.  No 
restrictions  will  be  placed  on  direct  two-way  com¬ 
munications  required  for  the  prosecution  of  the  Pro¬ 
gram/Project-  work  effort,  other  than  that  required 
for  security  purposes. 

1  Atch 
JOP  Format 

We  approve  this  Memorandum  of  Agreement  and  its 
implementing  regulation. 

Isl  HENRY  A.  MILEY,  JR. 

General,  USA 
Commanding  General 
US  Army  Materiel  Command 

Isl  l  C.  KIDD,  JR. 

Admiral,  USN 

Chief  of  Naval  Material 

Naval  Material  Command 

Isl  JACK  J.  CATTON 
General,  USAF 
Commander 

Air  Force  Logistics  Command 

Isl  GEORGE  S.  BROWN 
General,  USAF 
Commander 

Air  Force  Systems  Command 
20  July  1973 

1.  This  memorandum  of  agreement  is  published  as  a  joint  regulation, 
AFLC/AFSC  R  800-2.AMCR  70-59/NAVMATINST  5000.10A. 

Joint  AMC/NMC/ AFLC/AFSC  Operating 
Procedure  for 

I.  INTRODUCTION: 

This  paragraph  is  intended  to  give  a  description  and 
a  brief  review  of  the  functional  area  of  interest  in¬ 
cluding  why  the  JOP  is  necessary.  Outline  briefly  the 
overall  requirement  which  needs  fulfillment. 

II.  SCOPE: 

The  scope  will  outline  the  various  phases  of  the  Pro¬ 
gram/Project-  and  tie  down  the  overall  limits  of  the 
functional  area  of  interest  in  terms  of  time  and  any 
special  provisions  or  limitations. 

III.  REFERENCES: 

Include  all  applicable  AMC/NMC/AFLC/AFSC  regu¬ 
lations,  directives,  etc.,  that  are  pertinent  to  the  func¬ 
tional  area  of  interest. 


IV.  RESPONSIBILITIES: 

This  paragraph  is  intended  to  identify  the  relation¬ 
ships  and  responsible  entities  such  as  who  has  the 
overall  management  responsibility  and  who  has  the 
support  responsibility.  In  addition,  this  paragraph 
should  describe  what  the  “product”  or  the  effort 
should  be. 

V.  PROCEDURES: 

This  paragraph  should  define  the  work  to  be  accom¬ 
plished  and  indicate  the  main  steps  of  action,  in¬ 
cluding  coordination,  which  are  required  to  conduct 
the  tasks  involved  properly  in  developing  the  func¬ 
tional  area  of  interest. 

APPROVAL: 


Senior  Representative  Program/Project-Manager 

Participating  Service  Executive  Service 

Attachment  1 
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APPENDIX  B 

Charter  for  the  Joint  Project  Manager  For 

Advanced  Tactical  Aircraft  Protection 
Systems  (ATAPS)  (PMA272) 


1.  General 

a.  The  purpose  of  this  charter  is  to  establish  and 
promulgate  the  mission,  authority  and  responsibility 
of  the  Advanced  Tactical  Aircraft  Protection  Systems 
(ATAPS)  Project  Manager.  It  also  provides  for  the 
Project’s  scope,  operating  relationships,  organiza¬ 
tion  and  resources,  and  delineates  the  framework  for 
joint  Navy/Air  Force  participation  in  the  develop¬ 
ment  and  acquisition  of  systems  assigned.  Air  Force 
participation  in  ATAPS  is  limited  to  those  efforts 
covered  by  specific  memoranda  of  agreement.  The 
Chief  of  Naval  Material  assigned  executive  manage¬ 
ment  responsibility  to  the  Commander,  Naval  Air 
Systems  Command.  The  Commander,  Naval  Elec¬ 
tronic  Systems  Command  management  responsibility 
is  set  forth  in  the  applicable  memorandum  of  agree¬ 
ment. 

b.  The  following  memoranda  of  agreement  are 
applicable  to  the  ATAPS  Project  and  form  the  au- 
thoritive  basis  for  this  charter. 

(1)  Memorandum  of  Agreement  on  the  Man¬ 
agement  of  Multi-Service  Systems/Programs/Proj¬ 
ects,  dated  20  July  1973.  Signatories:  CG,  U.S.  Army 
Material  Command,  Chief  of  Naval  Material;  Com¬ 
mander,  Air  Force  Logistics  Command;  and  Com¬ 
mander,  Air  Force  Systems  Command. 

(2)  Memorandum  of  Agreement  for  the  Engi¬ 
neering  Development  Phase  One  of  the  Airborne 
Self  Protection  Jammer  (ASPJ)  Electronic  Warfare 
System,  dated  2  October  1978.  Signatories:  For  the 
Chief  of  Naval  Operations;  Director,  Tactical  Air  Sur¬ 
face  and  Electronic  Warfare  Development  Division 
(OP-982).  For  the  Chief  of  Staff  U.S.  Air  Force; 
Director,  Operational  Requirements,  DCS/Research 
and  Development.  (Note:  This  MOA  is  in  the  process 
of  being  revised  to  include  added  Air  Force  program 
scope  and  incorporate  Phase  Two  of  the  Full  Scale 
Development  Program.) 

(3)  Memorandum  of  Agreement  for  the  Super¬ 
vision  and  Support  of  the  ASPJ  Program,  dated 
4  May  1979.  Signatories:  Commander,  Naval  Air  Sys¬ 
tems  Command,  and  Commander,  Naval  Electronic 
Systems  Command. 


2.  System  Description. 

The  principal  developments  in  the  ATAPS  Project 
are  the  ASPJ  and  the  ALQ-131  Comprehensive 
Power  Management  System  (CPMS).  The  ASPJ  is  a 
modular,  low  cost,  lightweight,  electronic  warfare 
suite  for  Navy  and  Air  Force  tactical  attack  and 
fighter  aircraft.  It  will  provide  F/A-18,  F-14,  F-16  and 
other  designated  aircraft  with  a  wide  band  capability 
to  interrupt  or  deceive  modern  diversified  radar  con¬ 
trolled  anti-aircraft  weapons  systems.  The  CPMS  is  a 
receiver/controller  system  composed  primarily  of 
modules  common  to  the  ASPJ.  The  CPMS  is  de¬ 
signed  to  improve  the  performance  of  the  ALQ-131 
Pod. 

3.  Mission/Scope 

a.  The  Project  Manager’s  primary  mission  is  to 
provide  the  operating  forces  of  the  Navy  and  the  Air 
Force  fully  developed,  common,  supportable  and  re¬ 
liable  systems  which  will  satisfy  approved  operational 
requirements.  In  addition,  he  will  manage  the  acqui¬ 
sition  and  support  of  Foreign  Military  Sales  (FMS)  or 
other  Defense  security  assistance  programs. 

b.  The  scope  of  the  ATAPS  Project  consists  of 
the  definition,  development,  test  and  evaluation,  ac¬ 
quisition  and  logistics  support  of  the  system. 

4.  Project  Management 

a.  The  ATAPS  Project  will  be  planned,  organ¬ 
ized,  and  controlled  by  a  designated  joint  service 
Project  Office.  'Phis  Project  Office  will  be  responsive 
to  the  requirements  of  the  Navy  and  Air  Force  and 
will  be  the  single  point  of  contact  for  all  official  ac¬ 
tions  within  the  services  and  with  industry  during  the 
development  and  production  phases  of  the  project. 
Appendix  A  depicts  the  organizational  relationships 
of  the  project. 

b.  The  ATAPS  Project  Office  will  be  administra¬ 
tively  staffed  and  supported  in  accordance  with  the 
provisions  set  forth  in  the  current  memorandum  of 
agreement. 

c.  Funding.  The  applicable  Navy  program  ele¬ 
ment  is  PE  64226N  which  is  dedicated  to  the  ASPJ 
development.  Air  Force  funding  is  provided  to  the 
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Naval  Air  Systems  Command  through  Air  Force  Pro¬ 
gram  Element,  PE  64737F.  Air  Force  funds  are  ad¬ 
ministered  in  accordance  with  NAVAIRINST 
7020.2A. 

d.  Captain  W.  G.  Carlson,  USN,  is  the  ATAPS 
Project  Manager.  He  will  be  the  single  official  point 
of  contact  and  spokesman  for  the  DOD  on  all  as¬ 
signed  matters  related  to  the  ATAPS  Project. 

e.  An  Air  Force  officer  will  be  assigned  as  the 
ATAPS  Assistant  Project  Manager  and  in  this  capac¬ 
ity  is  second  in  charge  of  the  project.  He  also  func¬ 
tions  as  the  ATAPS  principal  management  represen¬ 
tative  for  Air  Force  programs.  He  will  be  located  in 
the  ATAPS  Project  Office  and  will  assist  the  ATAPS 
Project  Manager  in  the  management  of  the  ATAPS 
Project  Efforts  and  participate  in  all  actions  affecting 
these  efforts  including  the  management  of  the  Proj¬ 
ect  Office  staff.  He  will  be  the  Air  Force  representa¬ 
tive  for  the  Air  Force  unique  portion  of  the  project, 
including  responsibility  for  incorporation  of  all  Air 
Force  requirements  in  the  project;  and  the  negotia¬ 
tion  and  coordination  leading  to  final  approval  of 
joint  operating  procedures  needed  to  satisfy  the  sub¬ 
stantive  needs  of  the  Air  Force. 

f.  Functional  assistant  project  managers  in  the 
matrix  organizations  of  the  cognizant  systems  com¬ 
mands  will  be  assigned  to  the  project,  as  required. 
Air  Force  deputy  project  managers  will  be  assigned 
as  required  (i.e.,  Deputy  Project  Manager,  Logistics, 
with  duties  and  responsibilities  as  specified  in  the 
Joint  Service  Memorandum  of  Agreement,  Deputy 
Project  Manager,  Test,  etc.).  Appendix  B  illustrates 
the  organization  of  the  ATAPS  Project  Office. 

g.  Naval  laboratories,  weapons  and  test  centers, 
and  Air  Force  units  will  provide  technical  and 
development  support  under  the  direction  of  the  func¬ 
tional  assistant  project  managers  or  representatives 
of  the  Air  Force  as  appropriate.  See  Appendix  C  for 
a  list  of  activities  participating  in  the  project. 

h.  The  ATAPS  Project  Manager  will  be  fully  sup¬ 
ported  by  the  functional  organizations  of  the  Naval 
Air  Systems  Command  and  the  Naval  Electronic  Sys¬ 
tems  Command  in  accordance  with  the  current  mem¬ 
orandum  of  agreement.  Representatives  of  these 
organizations  will  be  assigned  as  members  of  the 
Project  Manager’s  team  and  will  plan  and  implement 
project  efforts  under  the  direction  of  the  Project 
Manager.  When  conflicts  between  project  and  func¬ 
tional  policies  and  objectives  develop  that  cannot  be 
resolved,  the  matter  will  be  referred  to  the  appro¬ 
priate  level  of  authority  for  resolution.  Actions 
directed  by  the  Project  Manager,  however,  shall  be 
instituted  during  the  period  pending  resolution. 


5.  Specific  Authority  and  Responsibilities 
of  the  Project  Manager 

a.  The  ATAPS  Project  Manager  is  the  single  cen¬ 
tral  executive  responsible  for  the  successful  manage¬ 
ment  of  the  project  and  accomplishment  of  the  objec¬ 
tives  in  this  charter.  He  has  broad  directive  authority 
within  the  scope  of  the  project  over  the  planning,  di¬ 
rection,  control,  and  utilization  of  resources  of  the 
approved  project  to  meet  Navy/Air  force  require¬ 
ments  and  assignment  of  responsibilities,  as  ap¬ 
propriate,  to  the  various  systems  commands  func¬ 
tional  organizational  elements.  As  the  responsible 
executive,  he  is  expected  to  act  on  his  own  initiative 
in  matters  affecting  the  project.  In  those  cases  where 
action  is  required  beyond  the  authority  granted  in 
this  charter,  he  shall  refer  the  action  to  appropriate 
higher  authority  in  his  Department  of  the  Navy 
and/or  the  Department  of  the  Air  Force  with  his 
recommendations,  including  available  alternatives. 

b.  The  ATAPS  Project  Manager  shall  have  the 
specific  authority  and  responsibility  to: 

(1)  Plan,  organize  and  administer  the  Project 
Office. 

(2)  Make  the  business  and  technical  manage¬ 
ment  decisions  authorized  by  the  project  charter  and 
required  for  successful  project  completion. 

(3)  Establish  detailed  initial  and  long-range 
project  objectives  in  compliance  with  the  formally 
established  requirements  of  the  Navy  and  Air  Force. 

(4)  As  appropriate,  direct  the  management  of 
test,  engineering  and  analytical  studies  required  in 
compliance  with  formally  established  requirements  of 
the  Navy  and  Air  Force. 

(5)  Manage  the  accomplishment  of  the  design, 
development,  test,  production  and  support  phases. 
Make  necessary  arrangements  for  technical  evalua¬ 
tions  and  furnish  such  assistance  as  may  be  required 
in  these  evaluations. 

(6)  Ensure  coordination  of  work  efforts  of  the 
Navy  and  Air  Force  activities  and  contractors  for  the 
project  to  prevent  unnecessary  duplication  of  effort. 

(7)  Approve  the  Navy  and  Air  Force  funding 
estimates  prior  to  incorporation  in  the  project  budget 
for  Five  Year  Defense  Program  elements  (or  parts 
thereof)  predominatly  identified  with  the  project. 

(8)  Direct  the  preparation,  submission,  and 
maintenance  of  Decision  Coordinating  Paper  171 
(DCP  171)  in  compliance  with  DOD  Directives  and 
implement  Navy  and  Air  Force  procedural  docu¬ 
ments  as  appropriate.  The  DCP  171  includes  Navy 
and  Air  Force  requirements. 

(9)  Exercise  financial  management  control  of 
the  utilization  of  all  Navy  and  Air  Force  funds  as- 
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signed  for  the  execution  of  the  project  in  accordance 
with  DOD  directives,  and  appropriate  Joint  Oper¬ 
ating  Procedures.  (See  paragraph  6c  for  additional 
information  concerning  Joint  Operating 
Procedures.)  Air  Force  unique  efforts  contracted  for 
by  Air  Force  agencies  are  excluded  from  the  ATAPS 
Project  Manager’s  financial  management  control. 

(10)  Define  the  work  efforts  to  be  undertaken 
by  contractors  and  Navy  and  Air  Force  activities  for 
the  project,  and  approve  the  proposed  plans  for  exe¬ 
cution,  scope  and  schedule  of  work,  and  the  costs  of 
work  efforts  requiring  project  funds.  The  ATAPS 
Project  Manager  may  delineate  the  degree  of  engi¬ 
neering  and  test  cognizance  to  be  exercised  within 
the  framework  prescribed  in  appropriate  Joint  Oper¬ 
ating  Procedures. 

(11)  Furnish  such  Navy  and  Air  Force  related 
information  and  requirements  as  may  be  necessary 
for  effective  procurement  planning  and  contract  ne¬ 
gotiations;  and  approve,  consistent  with  Defense  Ac¬ 
quisition  Regulations  (DAR)  and  effective  Navy  pro¬ 
curement  directives,  all  proposed  contractual  actions 
to  be  taken  to  satisfy  requirements.  The  contracting 
officer  will  assist  the  Project  Manager  and  keep  him 
advised  of  required  procurement  planning  and  other 
contractual  matters. 

(12)  Establish  and  promulgate  design  interface 
specifications  for  ATAPS  system  integration. 

(13)  Coordinate  appropriate  interface  segments 
of  the  project  with  appropriate  commands  of  the  Air 
Force  and  with  other  project  managers,  project  coor¬ 
dinators,  systems  commands,  and  Naval  Material 
Command  staff  elements  to  ensure  a  totally  coordi¬ 
nated  Navy/Air  Force  effort.  Furnish  necessary 
ATAPS  project  data  required  by  the  aircraft  systems 
project  managers  to  ensure  proper  integration  and 
compatibility  of  the  completed  systems  with  the  serv¬ 
ice  platforms.  Development,  procurement,  and  sup¬ 
port  of  ATAPS  related  equipment  peculiar  to  service 
platform  needs  such  as  mounting  hardware,  cabling, 
and  waveguide  configurations  are  the  responsibility 
of  the  aircraft  systems  project  managers.  Interface 
problems  not  resolved  shall  be  referred  directly  to 
the  appropriate  senior  management  official  within 
the  Naval  Material  Command  and  additionally  to  the 
Air  Force  Systems  Command/Air  Force  Logistics 
Command  in  the  event  the  problem  involves  an  Air 
Force  system  interface.  Specific  interface  require¬ 
ments  may  be  covered  in  appropriate  Joint  Operating 
Procedures. 

(14)  Establish  and  promulgate  criteria  for  con¬ 
tractor  test,  evaluation,  and  installation  of  systems, 
subsystems,  components,  equipment,  and  devices  as 
appropriate. 


(15)  Ensure  that  required  Ground  Support 
Equipment  (GSE)  and  test  equipment  are  developed 
and  procured  in  time  for  concurrent  delivery  with  the 
prime  equipment.  This  includes  purchasing  unique 
ASPJ  and  CPMS  support  equipment  where  this 
equipment  is  produced  by  the  prime  ASPJ/CPMS 
contractors.  When  required,  provide  advice,  guid¬ 
ance,  and  assistance  to  participating  organizations 
on  common  GSE  and  test  equipment  in  order  that 
they  may  plan,  procure,  and  effect  timely  deliveries  of 
such  equipment  in  support  of  project  deliveries.  Pro¬ 
cedures  to  carry  out  the  foregoing  may  be  prescribed 
in  an  appropriate  Joint  Operating  Procedure. 

(16)  Ensure  the  development,  maintenance, 
and  execution  of  Integrated  Logistics  Support  Plans 
for  the  project  in  compliance  with  current  DOD 
directives,  NAVMATINST  4000.20B  and  applicable 
Joint  Operating  Procedures.  Plans  will  include  all 
Navy  and  Air  Force  logistics  support  requirements 
for  the  project  as  appropriate. 

(17)  Exercise  overall  configuration  manage¬ 
ment  of  the  ATAPS  in  accordance  with  formal  re¬ 
quirements.  Establish  appropriate  methods  and  pro¬ 
cedures  to  implement  configuration  control  in  com¬ 
pliance  with  DOD  directives,  NAVMATINST 
4130.1  A  and  appropriate  NAVAIR  instructions.  Joint 
Operating  Procedures  for  ATAPS  may  be  estab¬ 
lished  as  required  to  augment  Navy  procedures  and 
assure  provision  of  essential  data  required  by  the  Air 
Force. 

(18)  Ensure  that  quality  assurance,  reliability, 
maintainability,  vulnerability,  safety,  value  engineer¬ 
ing,  electromagnetic  compatibility,  human  factors 
and  environmental  impact  aspects  of  the  project 
comply  with  DOD  directives  and  implementing  in¬ 
structions. 

(19)  Ensure  that  all  technical  documentation 
(including,  but  not  limited  to,  drawings,  illustrated 
parts  breakdowns,  and  technical  manuals),  regard¬ 
less  of  source,  is  prepared  in  compliance  with  current 
Navy  instructions  and  applicable  USAF  directives, 
and  is  available  in  usable  form  in  time  to  satisfy  the 
informational  needs  of  training,  operating  and  main¬ 
tenance  personnel.  All  technical  documentation  shall 
be  available  for  appropriate  delivery  with  the  system, 
subsystem,  components,  and  equipments.  This  re¬ 
quirement  also  includes  the  technical  documentation 
for  ground  handling,  test  and  support  equipment  in 
compliance  with  DOD  data  management  directives 
and  implementing  Navy  instructions.  These  re¬ 
quirements  may  be  included  in  appropriate  Joint 
Operating  Procedures. 

(20)  When  appropriate,  direct  the  procurement 
of  required  Navy  training  devices  and  equipments, 
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and  the  Air  Force  equivalents  of  such  equipments, 
including  spares  and  spare  parts.  Ensure  that  train¬ 
ing  plans  are  developed  by  cognizant  activities  to 
provide  the  required  integrated  training  plans  for 
Navy  and  Air  Force  instructors  and  operating  and 
maintenance  personnel.  These  requirements  may  be 
included  in  an  appropriate  Joint  Operating  Pro¬ 
cedure. 

(21)  Ensure  analysis  of  system,  subsystem,  and 
component  performance  in  relation  to  the  required 
performance  specifications,  and  direct  corrective  ac¬ 
tion  when  appropriate. 

(22)  Establish  necessary  management  control 
techniques  and  procedures  to  provide  accurate  and 
comprehensive  information  concerning  the  status 
and  progress  of  the  project  as  required  by  higher 
authority.  Require  participating  organizations  to 
keep  him  advised  of  the  status  and  progress  of  proj¬ 
ect  work  efforts  under  their  cognizance.  Use  existing 
management  systems,  procedures,  and  reporting 
systems  to  the  maximum  extent  possible,  supple¬ 
mented  as  necessary  with  USAF  management  pro¬ 
cedures  to  support  peculiar  Air  Force  needs.  When 
required,  on  a  case-by-case  basis,  provide  advice, 
guidance,  and  assistance  to  participating  organiza¬ 
tions  in  support  of  the  Cost  Information  Reports 
System. 

(23)  Furnish  necessary  project  data  required  by 
the  Air  Force,  naval  systems  commands,  project 
managers,  or  Navy  higher  authorities  for  preparation 
of  consolidated  reports  on  selected  categories  of 
hardware. 

(24)  Report  current  status  and  progress  of  the 
project  to  appropriate  Navy  and  Air  Force  depart¬ 
mental  officials  through  the  chain  of  command  with 
particular  emphasis  on  bringing  to  the  attention  of 
top  management  any  current  problems  which  will  ap¬ 
preciably  affect  present  or  future  project  status, 
scheduled  milestones,  system  performance,  or  costs. 

(25)  Furnish  to  all  participating  activities  cur¬ 
rent  information  on  project  plans  and  proposed 
changes  in  order  that  such  activities  may  update  and 
keep  current  their  detailed  plans  for  functions  for 
which  they  have  responsibility. 

(26)  Issue,  under  his  own  authority,  such  cor¬ 
respondence,  technical  directives,  management 
plans  and  project  directives  as  may  be  necessary  to 
ensure  that  plans,  budgets,  allocations,  and  sched¬ 
ules  in  support  of  the  project  are  properly  integrated 
and  time  phased.  Ensure  that  all  approved  corre¬ 
spondence  or  instructions  to  contractors  affecting 
the  terms  or  conditions  of  contracts  are  in  writing 
and  signed  by  the  appropriate  contracting  officer. 

(27)  Ensure  joint  participation  by  Navy/Air 


Force  representatives  in  technical  and  management 
decisions  relating  to  ATAPS. 

(28)  Ensure  compliance  with  the  Secretary  of 
Defense  and  the  Secretary  of  the  Navy  current  pro¬ 
posal  evaluation  and  source  selection  policies. 

(29)  When  appropriate,  establish  requirements 
for,  and  monitor  the  acquisition  of,  special  or  addi¬ 
tional  facilities  necessary  for  the  support  of  test, 
evaluation,  installation,  operation,  and  maintenance 
of  ATAPS  and  supporting  devices.  Ensure  that  the 
requirements  for  new  facilities  and  for  modifications 
to  existing  facilities  are  made  known  to  appropriate 
services  so  that  planning,  programming,  and  con¬ 
struction  schedules  will  be  responsive  to  support  of 
the  ATAPS. 

(30)  The  ATAPS  Project  Manager  will  ensure 
that  necessary  security  regulations  to  safeguard 
classified  material  are  instituted  in  accordance  with 
the  U.S.  Navy  Security  Manual.  He  will  disseminate 
appropriate  security  classification  guidelines  for  the 
project.  Decisions  related  to  security  problems  and 
the  administration  of  security  matters  will  be  pro¬ 
vided  by  the  Naval  Air  Systems  Command. 

(31)  The  ATAPS  Project  Manager  is  authorized 
to  prepare  and  sign  fitness  reports  for  all  military 
personnel  assigned  full-time  to  the  Project  Office, 
and  execute  performance  evaluations  as  applicable 
for  Navy  civilian  personnel  assigned  full-time  to  that 
office.  He  shall  submit  concurrent  fitness  reports  on 
other  officers  junior  to  him,  and  concurrent  evalua¬ 
tions  on  Naval  Material  Command  civilian  employees 
working  for  him  in  matrix  management  under  the  au¬ 
thority  of  this  charter.  Effectiveness  report/efficiency 
rating  procedures  for  Air  Force  personnel  assigned 
to  the  project  are  provided  in  the  joint  ASD / 
NAVAIR/AFALS  Memorandum  of  Agreement. 

(32)  The  ATAPS  Project  Manager  shall  main¬ 
tain  a  continuing  review  of  operational  requirements, 
including  inventory  objectives,  established  by  higher 
authority  for  his  project  to  ensure  timeliness,  accu¬ 
racy,  consistency,  and  compatibility.  When  inconsis¬ 
tent  and  incompatible  requirements  and  objectives 
cannot  be  resolved  by  the  Project  Manager,  the  prob¬ 
lems  and  recommendations  shall  be  submitted  in 
writing  to  the  Commander,  Naval  Air  Systems  Com¬ 
mand,  and  the  Deputy  Commander  for  Plans  and 
Programs,  or  an  appropriate  higher  authority  for  res¬ 
olution. 

(33)  The  ATAPS  Project  Manager  shall  main¬ 
tain  a  continuing  review  of  logistic  support  provided 
by  participating  organizations  to  ensure  that  such 
support  is  compatible  with  approved  project  and  op¬ 
erating  objectives.  When  deficiencies  in  such  support 
cannot  be  resolved  by  the  Project  Manager,  the  prob- 
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lems  and  recommendations  shall  be  submitted  in 
writing  to  the  Commander,  Naval  Air  Systems  Com¬ 
mand  and  appropriate  higher  authorities  for  reso¬ 
lution. 

c.  The  authority  and  responsibility  of  the  ATAPS 
Project  Manager  or  his  staff  shall  not  include: 

(1)  Deviations  from  established  Navy  and  Air 
Force  policies  except  as  specifically  waived. 

(2)  Approval  of  project  thresholds. 

(3)  Final  approval  of  procurement  plans,  ac¬ 
quisition  strategy,  decision  coordinating  paper  or 
other  top  level  documents  governing  the  conduct  of 
the  project. 

(4)  Changes  to  the  schedules  established  by 
higher  authority  for  deliveries  and  operational  use. 

(5)  Changes  degrading  mission  performance 
or  altering  operational  characteristics  specified  by 
higher  authority. 

(6)  Authority  to  act  as  the  ATAPS  Contracting 
Officer  in  the  execution  of  contracts  or  changes 
thereto. 

d.  The  ATAPS  Project  Manager  receives  his 
authority  from  and  is  ultimately  responsible  and  ac¬ 
countable  to  the  Commander,  Naval  Air  Systems 
Command  for  the  discharge  of  the  latter's  responsi¬ 
bility  relative  to  the  project.  He  is  authorized  direct 
access  to  the  Commander  from  whom  he  receives 
broad  policy  determination  and  requirements  defini¬ 
tion.  For  guidance  and  assistance,  the  Project  Mana¬ 
ger  shall  report  to  the  Deputy  Commander  for  Plans 
and  Programs  who  exercises  broad  direction  and  life 
cycle  management  coordination  over  the  project. 
Within  the  Naval  Electronic  Systems  Command,  he 
is  assigned  to  the  Manager,  REWSON  (Reconnais¬ 
sance  Electronic  Warfare  Special  Operations  NIPS 
(Naval  Intelligence  Processing  Systems))  Systems 
Project  (PME107)  for  centralized  integration  and 
coordination  of  the  ATAPS  Project  with  the  total 
REWSON  System  Project.  The  ATAPS  Project  Man¬ 
ager  will  also  keep  the  Deputy  Commander  for  Plans 
and  Programs  informed  of  status,  progress  and  prob¬ 
lems  related  to  this  project. 

e.  The  ATAPS  Project  Manager  is  authorized 
direct  contact  with  all  activities  concerned  with  the 
project.  Initially  these  contacts  will  be  made  through 
the  cognizant  Air  Force  command,  the  cognizant 
Naval  Systems  command,  or  appropriate  manage¬ 
ment  office.  The  ATAPS  reporting  authority,  the 
Deputy  Commander  for  Plans  and  Programs,  will  be 
informed  of  all  nonroutine  contacts. 

6.  Specific  Interface  and  Operating 
Relationships 

a.  Navy  (j Requirements  Applicable  Only  to  Navy 


Internal  Operating  Relationships).  The  ATAPS  Pro¬ 
ject-  Manager  will: 

(1)  Provide  data  relevant  to  Foreign  Military 
Sales  (FMS)  caseV2 assignments.  When  required  by 
the  recipient  foreign  country,  the  Project-  Manager 
will  provide  overall  initiation,  guidance,  coordina¬ 
tion,  and  review  of  United  States  contracts/Navy  ef¬ 
forts  in  logistically  supporting  and  sustaining  in¬ 
country  inventory  of  systems  under  his  cognizance. 
The  Project- Manager  also  will  maintain  close  liaison 
with  a  maximum  responsiveness  to  the  Defense  Secu¬ 
rity  Assistance  Office  (AIR-103),  the  Deputy  Chief  of 
Naval  Material  for  Security  Assistance  (MAT-08F), 
and  OPNAV  (OP-63)  on  FMS  matters. 

(2)  Maintain  active  liaison  with  cognizant 
members  of  the  Naval  Material  Command  staff  and 
with  the  OPNAV  Program  Coordinator,  OP-506G,  in 
accordance  with  the  Navy  Programming  Manual.  The 
Project-  Manager  shall  keep  the  foregoing  personnel 
fully  informed  of  the  status  and  progress  of  the  proj¬ 
ect  through  formal  and  informal  relationships. 

(3)  Coordinate  project  matters  with  other  ap¬ 
plicable  project  managers  and  project  coordinators. 
Specifically,  the  ATAPS  Project  Manager  is  required 
to  work  closely  with  the  airframe  PMAs  whose  air¬ 
craft  are  designated  to  receive  or  are  candidates  for 
the  ASPJ.  These  PMAs  are  PMA234  (A-6E/EA-6B), 
PMA241  (F-14),  PMA257  (AV-8B),  and  PMA265 
(F/A-18).  In  addition  to  the  airframe  PMAs,  close 
contact  must  be  maintained  with  PMA253  (REWS) 
to  coordinate  the  overall  Tactical  Air  Electronic 
Warfare  Program  and  with  PMA242  (Defense  Sup¬ 
pression)  to  coordinate  the  lethal  and  nonlethal 
aspects  of  Defense  Suppression.  Liaison  with  Air 
Force  commands  and  activities  will  be  in  accordance 
with  the  governing  memorandum  of  agreement. 

(4)  Keep  the  Office  of  the  Deputy  Chief  of 
Naval  Operations  (Manpower)  (OP-01),  Commander, 
Naval  Material  Command,  and  Headquarters,  Marine 
Corps,  fully  informed  of  the  military  personnel  re¬ 
quirements  of  the  project.  Personnel  requirements 
normally  will  be  transmitted  to  OP-01  and  the 
Marine  Corps  through  the  Program  Coordinator 
within  the  Office  of  the  Deputy  Chief  of  Naval  Opera¬ 
tions  (AIR). 

b.  Air  Force.  Either  the  ATAPS  Project  Manager 
or  the  Air  Force  Assistant  Project  Manager  will  be  re¬ 
sponsible  for  coordinating  ATAPS  matters  with  vari¬ 
ous  Air  Force  commands  including,  but  not  limited 
to,  Headquarters,  USAF;  Air  Force  Systems  Com¬ 
mand;  Air  Force  Logistics  Command;  Tactical  Air 
Command;  Air  Training  Command;  and  Air  Force 
Test  and  Evaluation  Center.  Interactions  usually  will 
be  effected  by  the  Air  Force  Assistant  Project 
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Manager. 

c.  Joint  Operating  Procedures 

(1)  Joint  Operating  Procedures  may  be  nego¬ 
tiated  and  executed  between  the  Navy  and  Air  Force 
as  required  to  clearly  define  the  procedures  to  be 
followed  by  each  service  in  meeting  total  ATAPS  re¬ 
quirements.  The  areas  listed  below  are  candidate 
subjects  for  Joint  Operating  Procedures: 

(a)  Engineering  and  test  cognizance 

(b)  Configuration  management 

(c)  Procurement  and  production 

(d)  Integrated  Logistics  Support 

(e)  Financial  management  and  status  re¬ 
porting  (Project-  Control) 

(f)  Personnel  subsystem  including  training 

(g)  Systems  safety 

(h)  Data  management 

(i)  Maintainability/reliability 

(j)  Administration 

(k)  Additional  Joint  Operating  Procedures 

(2)  The  Joint  Operating  Agreements  appear¬ 
ing  in  the  Standard  Integrated  Support  Management 
System  (SISMS)  Manual,  AFLCR/AFSCR  800-24, 
NAVMATINST  4000.38,  AMCR  700-97,  and  MCOP 
4110.1A  dated  16  November  1978  will  be  used  as  the 
baseline  where  appropriate,  for  developing  the  Joint 
Operating  Procedures  for  this  project. 

(3)  The  ATAPS  Project  Manager  and  his  Air 
Force  assistant  are  authorized  to  negotiate  and 
direct  execution  of  Joint  Operating  Procedures. 
Cognizant  commands  will  assist  in  the  negotiation 
and  execution  of  these  procedures  and  agreements. 

7.  Logistics  Organizations  Furnishing 

Support  to  the  Project 

a.  The  ATAPS  Project  Manager  will  be  responsi¬ 
ble  for  the  procurement  of  initial  quantities  of  spares 
and  repair  parts,  test  and  special  support  equipment, 
technical  documentation,  trainers,  training  equip¬ 
ment,  and  devices  for  both  the  Navy  and  Air  Force 
through  the  contractor  and  appropriate  Navy  logistic 
support  activities. 

b.  The  Deputy  Program  Manager  for  Logistics 
will  manage  the  logistics  and  support  activities  on 
behalf  of  the  ATAPS  Project  Manager  and  will  coor¬ 
dinate  and  implement  these  activities  for  both  Navy 
and  Air  Force  requirements. 

c.  Navy.  The  Naval  Air  Systems  Command  and 
the  Naval  Supply  Systems  Command,  through  their 
commodity  managers,  will  provide  Navy  follow-on  re¬ 
plenishment  support. 

d. Air  Force.  The  Air  Force  Logistics  Command, 
through  its  Item  Manager,  will  provide  Air  Force 
follow-on  support. 


8.  Organizations  Performing  Test, 

Demonstration,  and  Evaluation 

a.  Contractor  test  and  demonstrations  will  be 
performed  in  accordance  with  the  terms  of  the 
original  and  follow-on  contracts  for  specific  systems. 
Operational  tests  and  evaluations  will  be  performed 
by  each  service  to  meet  its  own  requirements.  Coor¬ 
dinated  testing  will  be  conducted  on  items  of  mutual 
interest. 

b.  Various  Navy/Air  Force  test  and  evaluation  ac¬ 
tivities,  as  applicable,  may  be  required  to  conduct 
flight  and  ground  test  of  Navy  and/or  Air  Force 
equipments.  Funding  support  and  requirements  for 
the  tests  will  be  as  prescribed  in  an  appropriate  Joint 
Operating  Procedure. 

c.  The  Deputy  Program  Manager  for  Test  and 
Evaluation  will  manage  the  test  activities  on  behalf  of 
the  ATAPS  Project  Manager  and  will  coordinate  and 
implement  these  activities  for  both  Navy  and  Air 
Force  requirements. 

9.  Organizations  Preparing  Training 

Plans  and  Procuring  Training  Devices 

and  Aids 

a.  The  ATAPS  Project  Manager  may  be  required 
to  coordinate  Navy  training  requirements  for  instruc¬ 
tors  and  maintenance  personnel  in  accordance  with 
plans  approved  by  the  Chief  of  Naval  Operations. 

b.  The  ATAPS  Project  Manager  may  be  required 
to  coordinate  Air  Force  training  requirements  in  ac¬ 
cordance  with  plans  approved  by  the  Air  Training 
Command.  Implementation  will  be  incorporated  in 
an  appropriate  Joint  Operating  Procedure. 

10.  Assignment  and  Assessment  of 
Resources 

a.  Resources  Assigned 

(1)  Funds.  Funds  listed  in  current  allocations 
are  assigned  to  the  ATAPS  Project  Manager  for  obli¬ 
gation  in  the  execution  of  the  project  objectives.  Air 
Force  funds  will  be  identified  on  MIPRs  (Military  In¬ 
terdepartmental  Purchase  Requests)  prepared  by  the 
Air  Force.  Reprogramming  of  ATAPS  funds  below 
threshold  limits  is  not  authorized  except  upon  ap¬ 
proval  of  the  ATAPS  Project  Manager.  In  general, 
these  funds  will  cover  procurement  of  all  material 
and  services  needed  to  satisfy  Air  Force  ATAPS  re¬ 
quirements. 

(2)  Utilization  of  Activities.  Organizational 
elements  participating  in  the  project  and  performing 
tasks  assigned  by  the  Project  Manager  are  listed  in 
Appendix  C.  For  activities  under  the  Commander, 
Naval  Air  Systems  Command  and  the  Commander, 
Naval  Electronic  Systems  Command,  the  Project 
Manager  shall  have  the  authority  to  assign  tasks  or  to 
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direct  the  assignment  of  tasks.  Requirements  for 
tasks  to  be  performed  by  the  Air  Force  activities  shall 
be  coordinated  by  the  Air  Force  Assistant  Project 
Manager.  For  other  activities,  official  correspond¬ 
ence  will  be  utilized  to  request  the  assistance  re¬ 
quired. 

(3)  Manpower.  The  manpower  resources  cur¬ 
rently  required  to  staff  and  operate  the  ATAPS  Proj¬ 
ect  Office  are  identified  in  Appendix  D.  Periodically  a 
review  of  manpower  resources  will  be  conducted. 

(4)  Administrative  Support.  The  ATAPS  Proj¬ 
ect  Office  will  be  administratively  supported  by  the 
Naval  Air  Systems  Command  and  the  Naval  Elec¬ 
tronic  Systems  Command  in  accordance  with  the 
provision  of  the  current  NAVAIR/NAVELEX  Memo¬ 
randum  of  Agreement.  This  support  will  include,  but 
not  be  limited  to,  Navy  military  personnel  services, 
Navy  civilian  personnel  services,  space  allocations, 
office  services,  security,  graphic  arts,  communica¬ 
tions,  Navy  travel,  and  contracting,  as  appropriate. 
The  Naval  Data  Automation  Command  will  provide 
administrative  support  for  financial  reporting  serv¬ 
ices  and  computer  services  in  accordance  with  estab¬ 
lished  procedures.  Travel  support  for  Air  Force  per¬ 
sonnel  outside  the  ATAPS  Project  Office  will  be  pro¬ 
vided  in  accordance  with  Air  Force  procedures. 

b.  Resources  Assessment 

(1)  The  ATAPS  Project  Manager  shall  eval¬ 
uate  and  document  the  effect  of  proposals  to  in¬ 
crease  or  decrease  the  resources  authorized  for  the 
execution  of  the  project  and  shall  determine  the  ef¬ 
fect  of  the  proposed  changes  on  approved  cost, 
schedules,  procurement  plans,  and  performance  ac¬ 
tivities.  This  evaluation  shall  be  conducted  in  con¬ 
junction  with  the  Air  Force  Assistant  Project  Mana¬ 
ger  on  matters  of  concern  to  the  Air  force.  The  Proj¬ 
ect  Manager’s  evaluation  will  be  considered  by  offi¬ 
cials  having  final  decision  authority  during  program¬ 
ming  and  budget  deliverations. 

(2)  The  Chief  of  Naval  Operations  and  the 
Chief  of  Naval  Material,  and  appropriate  Air  Force 
commands  and  headquarters,  shall  be  informed 
through  channels  in  any  instance  where  the  re¬ 
quirements  of  the  Project  cannot  be  met  within  the 
resources  and  time  available. 

11.  Operating  Parameters 

Specific  performance,  supportability,  funding, 
schedule  constraints  and  thresholds  are  set  forth  in 
the  current  issue  of  DCP-171. 

12.  Public  Information 

The  Navy,  as  Executive  Service,  will  be  responsible 
for  the  coordination  and  dissemination  of  public  in¬ 
formation  relating  to  ATAPS.  The  responsibility  for 


provision  of  information  to  legislative  bodies,  indus¬ 
try  and  to  the  general  public  has  been  delegated  to 
the  Legislative  and  Information  Office  (AIR-OOD). 

13.  Project  Withdrawal,  Transition  and 
Disestablishment 

a.  This  project  will  be  reviewed  periodically 
to  determine  if  it  has  accomplished  its  objectives.  If 
the  review  indicates  the  objectives  have  been  or  are 
about  to  be  accomplished,  a  transition  plan  shall  be 
promulgated  to  insure  a  smooth  disposition  of  re¬ 
maining  resources,  responsibilities,  and  functions. 

b.  The  withdrawal  of  either  participating  service 
from  the  production  phases  of  the  ATAPS  Project 
shall  be  fully  coordinated  with  the  other  service. 
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APPENDIX  B 

ATAPS  PROJECT  ORGANIZATION 
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APPENDIX  C 

ACTIVITIES  PARTICIPATING  IN  PROJECT 


Activity 

PRINCIPAL  ACTIVITIES 

Naval  Material  Command 
Naval  Air  Systems  Command 
Naval  Electronic  Systems  Command 
Air  Force  Systems  Command 
Air  Force  Logistics  Command 

SUPPORT  ACTIVITIES 

NAVY 


Location 


Washington  DC 
Washington,  DC 
Washington,  DC 
Andrews  AFB,  MD 
Wright-Patterson  AFB,  OH 


Naval  Training  Equipment  Center 
Navy  Aviation  Supply  Office 
Naval  Research  Laboratory 
Pacific  Missile  Test  Center 
Naval  Air  Test  Center 

AIR  FORCE 


Orlando,  FL 
Philadelphia,  PA 
Washington  DC 
Pt  Mugu,  CA 
Patuxent  River,  MD 


Aeronautical  Systems  Division 
Air  Force  Acquisition  Logistics  Division 
Air  Force  Test  and  Evaluation  Center 
Armament  Division 
Hq.  Air  Training  Command 
Hq.  Tactical  Air  Command 
Warner-Robins  Air  Logistics  Center 
Ogden  Air  Logistics  Center 

It  is  anticipated  that  additional  activities  may  be  required  to  participate 
APPENDIX  C 
ENCLOSURE  (1) 


Wright-Patterson  AFB  OH 
Wright  Patterson  AFB,  OH 
Kirtland  AFB,  NM 
Eglin  AFB,  FL 
Randolph  AFB,  TX 
Langley  AFB  VA 
Robins  AFB,  GA 
Hill  AFB,  UT 

in  the  execution  of  the  ATAPS  Project. 
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APPENDIX  D 
MANPOWER  RESOURCES 


Title 

ATAPS  Project  Office 
Project  Manager 

Assistant  Project  Manager  and  Deputy  Project 
Manager,  Air  Force  Program 

Deputy  Project  Manager,  Systems 

Deputy  Project  Manager,  Test 

Configuration/Data  Control  Manager 

Business/Financial  Manager 

Program  Manager 

Deputy  Project  Manager,  Logistics 

Secretary 

Secretary 

NAVAIR  Assistant  Project  Managers 
Contracting 

Development  (Technical  and  Systems) 
Logistics 

T&E  Coordination 
Production 
APPENDIX  D 
ENCLOSURE  (1) 


Source 


Navy  (NAVAIR) 
Air  Force 

Navy  (NAVELEX) 
Air  Force 
Navy  (NAVAIR) 
Navy  (NAVELEX) 
Air  Force 
Air  Force 
Air  Force 
Navy 

AIR-215 

AIR-5332 

Air-4112 

AIR-620C 

ESA 
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APPENDIX  C 
Test  and  Evaluation 
Centers 


ARMY 

—  The  U.S.  Army  Operational  Test  and  Evaluation 
Agency  (OTEA)  has  the  responsibility  for  the 
conduct  of  all  U.S.  Army  major  and  Category  1 
operational  testing.  OTEA  has  no  testing  facili¬ 
ties  of  their  own  and  only  a  small  staff.  OTEA 
may  manage  or  merely  monitor  tests  at  any  of 
the  sites  listed  below. 

The  Training  and  Doctrine  Command 
(TRADOC)  is  responsible  for  all  Category  II  and 
below  and  OTEA  assigned  systems  operational 
testing,  as  well  as  concept  evaluation  testing, 
force  development  and  training  experimentation 
(FDTE),  or  any  other  user  tests  as  may  be  pre¬ 
scribed  to  answer  issues  in  doctrine,  tactics,  and 
operation.  TRADOC  agencies/commands/ 
boards  are  as  follows: 

-  TRADOC  Combined  Army  (TCATA),  Ft. 
Hood,  TX  -  large  scale  field  experiments 
and  operational  testing  up  to  corps  size. 

—  Combat  Developments  Experimentation 
Command  (CDEC),  Ft.  Ord,  CA  -  small 
scale,  high  resolution,  highly  instrumented 
tests  of  small  units  (company  size  and 
below). 

—  U.S.  Army  Aviation  Board,  Ft.  Rucker,  AL 
—  U.S.  Army  Armor  and  Engineering  Board, 
Ft.  Knox,  KY 

—  U.S.  Army  Air  Defense  Board,  Ft.  Bliss,  TX 
—  U.S.  Army  Airborne  Board,  Ft.  Bragg.  NC 
—  U.S.  Army  Communications/Electronics 
Board,  Ft.  Gordon,  GA 

—  U.S.  Army  Field  Artillery  Board,  Ft.  Sill,  OK 
—  U.S.  Army  Infantry  Board,  Ft.  Benning,  GA 
—  U.S.  Army  Intelligence  and  Security  Board, 
Ft.  Huachuca,  A Z 

—  U.S.  Army  Test  and  Evaluation  Command 
(TECOM).  Headquartered  at  the  Aberdeen  Prov¬ 
ing  Ground,  Maryland.  TECOM  is  the  primary 
developmental  test  agency  for  the  Army.  Activi¬ 
ties  and  installations  of  TECOM  include: 

—  Aberdeen  Proving  Ground,  Maryland  - 
testing  of  all  weapons  (except  nuclear 
weapons)  and  wheeled  and  tracked  vehicles. 
—  Cold  Regions  Test  Center,  Fort  Greely, 


Alaska  -  environmental  testing  of  all  types 
of  material  under  extreme  conditions 
—  U.S.  Army  Aircraft  Development  Test  Ac¬ 
tivity,  Fort  Rucker,  Alabama  -  testing  of 
aircraft  components  and  aircraft  support 
equipment 

—  U.S.  Army  Dugway  Proving  Ground,  Utah  - 
testing  of  chemical  and  radiological  defense 
material  and  systems 

—  Electronic  Proving  Ground,  Fort  Huachuca, 
Arizona  -  testing  of  communications  and 
electronic  equipment 

—  Jefferson  Proving  Ground,  Indiana  - 
testing  of  ammunition 

—  White  Sands  Missile  Range,  New  Mexico  - 
testing  of  missiles,  missile  systems  and  space 
systems 

—  Tropic  Test  Center,  Panama  -  environ¬ 
mental  testing  of  all  types  of  material  and 
equipment 

—  Yuma  Proving  Ground,  Arizona  -  environ¬ 
mental  and  general  testing  of  weapons,  mu¬ 
nitions  and  automotive  systems  and  equip¬ 
ment 

—  Kwajalein  Missile  Range,  Pacific  -  testing 
of  missiles,  missile  systems  and  space 
systems 

—  U.S.  Army  Material  Systems  Analysis  Activity 
(AMSAA).  Also  at  the  Aberdeen  Proving 
Grounds.  AMSAA  provides  the  central  inde¬ 
pendent  materiel  and  weapons  effectiveness 
studies  and  analyses  for  the  Army  Material  De¬ 
velopment  and  Readiness  Command 
(DARCOM).  AMSAA  also  performs  reliability, 
availability,  and  maintainability  studies,  and  in¬ 
dependent  evaluations  of  development  tests  con¬ 
ducted  by  other  DARCOM  test  activities. 

—  Laboratories  and  test  centers  of  each  of  the  indi¬ 
vidual  product-oriented  Research  and  Develop¬ 
ment  Commands: 

—  Armament;  Aberdeen,  Maryland  and  Ft. 

Picatinny,  New  Jersey 
—  Aviation;  St.  Louis,  Missouri 
—  Communications;  Ft.  Monmouth,  New 
Jersey 
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—  Mobility  Equipment;  Fort  Belvoir,  Virginia 

—  Missiles;  Redstone  Arsenal,  Alabama 

—  Tank-Automotive;  Warren,  Michigan 

—  Electronics;  Adelphi,  Maryland 

—  Food,  Tools,  Support  Equipment;  Natick, 
Masachusetts 


NAVY 

—  Naval  Research  Laboratory  (NRL).  Located  at 
Washington,  D.C.,  NRL  functions  as  the  cor¬ 
porate  research  laboratory  of  the  Navy  in  a 
broadly  based  multi-disciplinary  program  of 
scientific  research  and  advanced  technological 
development. 

—  Naval  Air  Development  Center  (NADC).  NADC, 
at  Warmister,  Pennsylvania  is  the  principal 
RDT&E  center  for  naval  aircraft  systems. 

—  Naval  Coastal  Systems  Laboratory  (NCSL). 
Located  at  Panama  City,  Florida,  NSCL  is  the 
principal  RDT&E  center  for  the  application  of 
science  and  technology  associated  with  military 
operations  executed  in  coastal  regions. 

—  David  Taylor  Naval  Ship  Research  and 
Development  Center  (DTNSRDC).  Head¬ 
quartered  and  principally  located  in  Bethesda 
(Carderock),  Maryland,  DTNSRDC  is  the  prin¬ 
cipal  RDT&E  center  for  naval  vehicles  and  pro¬ 
vides  RDT&E  support  for  the  U.S.  maritime  in¬ 
dustry. 

—  Naval  Surface  Weapons  Center  (NSWC).  Head¬ 
quartered  at  Silver  Spring  (White  Oak), 
Maryland,  with  additional  facilities  at  Dahlgren, 
Virginia,  NSWC  is  the  principal  RDT&E  center 
for  naval  surface  warfare  weapons  systems. 

—  Naval  Undersea  Center  (NUC).  NUC  at  San 
Diego,  California,  is  the  principal  RDT&E 
center  for  undersea  surveillance  and  advanced 
undersea  weapons. 

—  Naval  Underwater  Systems  Center  (NUSC). 
With  headquarters  at  Newport,  Rhode  Island, 
and  facilities  there  and  at  New  London, 
Connecticut,  NUSC  is  the  principal  RDT&E 
center  for  underwater  weapons  systems. 

—  Naval  Weapons  Center  (NWC).  NWC  at  China 
Lake,  California,  is  the  principal  Navy  RDT&E 
center  for  air  warfare  and  missile  systems. 

—  Atlantic  Underseas  Test  and  Evaluation  Center 
(AUTEC).  Headquartered  at  West  Palm  Beach, 
Florida,  with  facilities  in  the  Caribbean  Sea, 
AUTEC  provides  a  deepwater  test  and  evalua¬ 
tion  facility  for  ship,  sensor,  and  underwater 
weapons  systems. 


—  Naval  Air  Engineering  Center  (NAEC).  The 
NAEC  at  Lakehurst,  New  Jersey,  conducts 
RDT&E  for  aircraft  launching  and  recovery  sup¬ 
port  systems  and  ground  support  equipment. 

—  Naval  Air  Propulsion  Center  (NAPC).  Located  in 
Trenton,  New  Jersey,  NATPC  tests  and 
evaluates  aircraft  propulsion  systems. 

—  Naval  Air  Test  Center  (NATC).  The  NATC  at 
Patuxent,  Maryland,  performs  T&E  of  aircraft 
and  weapons  systems  and  ground  support  equip¬ 
ment. 

—  Atlantic  Fleet  Weapons  Training  Facility 
(AFWTF).  Headquartered  at  Roosevelt  Roads, 
Puerto  Rico,  and  with  facilities  spread 
throughout  the  Caribbean  area,  AFWTF  sup¬ 
ports  development  and  testing  of  ship  and  air 
weapons  systems  and  fleet  training. 

—  Pacific  Missile  Test  Center  (PMTC).  Head¬ 
quartered  at  Point  Mugu,  California,  PMTC  pro¬ 
vides  range  facilities  and  support  for  RDT&E  of 
DOD  missile,  satellite  and  space  vehicle  pro¬ 
grams. 

—  Naval  Weapons  Evaluation  Facility  (NWEF). 
The  NWEF  at  Albequerque,  New  Mexico,  per¬ 
forms  T&E  and  provides  technical  support  for 
weapons  systems. 


MARINE  CORPS 

—  Marine  Corps  Development  and  Education  Com¬ 
mand  (MCDEC).  The  MCDEC  at  Quantico, 
Virginia,  inter  alia,  performs  RDT&E  for  Marine 
Corps  doctrine  and  equipment. 


AIR  FORCE 

—  Air  Force  Flight  Test  Center  (AFFTC).  Located 
at  Edwards  AFB,  California,  AFFTC  conducts 
development  test  and  evaluation  of  manned  and 
unmanned  aerospace  vehicles  at  Edwards  AFB. 
Operates  the  Utah  Test  and  Training  Range 
(UTTR). 

—  Armament  Division  (AD).  AD,  at  Eglin  AFB, 
Florida,  conducts  development  testing  of  elec¬ 
tronic  warfare  systems  and  nonnuclear  muni¬ 
tions. 

—  Arnold  Engineering  Development  Center 
(AEDC).  AEDC  performs  flight  test  simulation 
for  air-breathing  and  rocket  engines  and  space 
and  reentry  vehicle  test  and  simulation  at  Arnold 
AFS,  Tennessee. 

—  Western  Space  and  Missile  Center  (WSMC). 
WSMC  manages  and  operates  the  Western  Test 
Range  providing  launch  operations  and  con- 
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tinuous  trajectory  coverage  of  a  broad  portion  of 
the  Western  U.S.  and  the  Pacific  Ocean. 
Eastern  Space  and  Missile  Center  (ESMC). 
Headquartered  at  Patrick  AFB,  Florida,  ESMC 
conducts  Air  Force  launch  operations  from  Cape 
Canaveral  AFS,  Florida,  and  provides  range  sup¬ 
port  for  Air  Force,  Navy  and  NASA  launch 
operations  in  the  Atlantic  Ocean  area. 

The  6585th  Test  Group.  Located  at  Holloman 
AFB,  operates  the  High  Speed  Test  Track,  the 
Radar  Target  Scatter  Facility  (RATSCAT)  and 
the  Central  Inertial  Guidance  and  Test  Facility 
(CIGTIF). 

The  4950th  Test  Wing.  Conducts  avionics  and 
systems  testing  in  areas  of  navigation,  com¬ 
munications,  lasers,  and  radars.  Operates  the 
Aircraft  Major  Modifications  Center  (AFSC). 
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APPENDIX  D 

Instructions  for  the  Preparation  of  Joint 
Integrated  Logistics  Support  Plans 

(JILSP) 


1.  How  To  Prepare  and  Use  the  JILSP: 

a.  Preparation  of  the  JILSP  should  be  the 
responsibility  of  the  executive  service.  Participating 
services  should  provide  a  central  point  of  contact  for 
coordination  of  the  plan  in  their  service. 

b.  The  JILSP  begins  as  a  broad,  objective- 
oriented  document  in  the  conceptual  phase  and 
becomes  a  more  specific  tasking  and  milestone 
scheduling  document  as  a  program  progresses 
through  the  acquisition  process.  The  JILSP  should 
be  tailored  to  the  characteristics,  needs,  and  complexity 
of  each  program  and  official  program  direction. 

c.  In  preparing  the  JILSP,  emphasize  the  specific 
tasks  to  be  accomplished,  who  is  responsible  for  the 
tasks,  and  the  schedule  for  joint  task.  Brievity  is 
essential;  make  all  entries  clear  and  concise.  Keep 
narrative  material  to  a  minimum.  Do  not  repeat  in¬ 
formation  from  other  documents,  unless  it  is  needed 
to  understand  the  JILSP.  In  tailoring  the  JILSP  to 
the  individual  program,  be  innovative  to  accom¬ 
modate  unique  program  features  consistent  with 
comprehensive  ILS  planning. 

d.  Begin  developing  the  JILSP  during  the 
concept  ual  phase  of  a  program  as  part  of  the  acquisi¬ 
tion  strategy.  Guidance  for  preparation  of  the  JILSP 
is  included  in  paragraph  3. 

e.  Coordinate  the  JILSP  with  all  participating 
and  affected  organizations.  When  signed  by  the  PM, 
the  JILSP  becomes  the  ILS  implementation  plan  that 
all  participating  activities  must  comply  with. 

f.  Develop  the  JILSP  so  it  can  be  used  as  a  daily 
“working  document”  by  working  level  personnel. 

(1)  Part  I  (General)  and  Part  II  (Concept/ 
Strategy)  contain  all  narrative  portions  of  the  plan. 
Narratives  are  not  needed  for  any  ILS  function  for 
which  a  milestone  schedule  chart  is  developed.  While 
some  general  information  may  be  necessary,  those 
features  and  innovative  techniques  that  are  unique  to 
the  system  must  be  identified.  The  narrative  portion 
of  the  plan  will  be  constructed  so  that  changes  are 
only  required  when  basic  objectives,  concepts,  or 
criteria  are  modified. 

(2)  Part  III  of  the  JILSP  is  made  up  of  indi 
vidual  milestone  charts  that  can  be  easily  updated  to 


show  program  status  and  to  identify  the  interfaces 
where  a  change  to  a  specific  task  affects  another 
task(s)  within  any  milestone  schedule  chart.  When  a 
computer-supported,  program  management  informa¬ 
tion  system  is  used  to  reflect  program  status,  con¬ 
sider  using  the  computer  system  output  products  as 
Part  III  of  the  JILSP.  Exercise  caution  to  ensure  that 
the  outputs  used  are  clear  and  complete  enough,  can 
be  easily  understood  by  reviewers  and  users  of  the 
JILSP  without  extensive  study. 

g.  Services  differences  in  ILS  planning  should 
be  incorporated  into  the  basic  JILSP  as  an  integral 
part  of  the  planning  process  for  the  individual 
elements. 

2.  JILSP  Reviews. 

Review  and  update  the  JILSP  whenever  new 
program  direction  is  received  or  changes  occur  that 
warrant  realignment  of  logistics  support  planning. 

Keep  a  log  of  the  last  time  each  page  was  reviewed 
and  updated. 

3.  JILSP  Format: 

a.  Part  I— General 

(1)  System  Description— Briefly  describe  the 
system  and  equipment,  its  purpose,  and  general  per¬ 
formance  characteristics. 

(2)  Program  Management— Identify  all  partic¬ 
ipating  organizations  and  whether  it  is  applicable  to 
security  assistance  programs. 

(3)  Applicable  Documents— Identify  those 
documents  that  provide  guidance  or  criteria 
necessary  to  accomplish  functions  described  in  the 
JILSP. 

b.  Part  II— Concepts/Strategy: 

(1)  Operations  Concept— Briefly  describe  the 

operational  concept  in  terms  of  mission  scenarios, 
operational  environment,  employment  concepts,  and 
deployment  plans.  Provide  sufficient  detail  (annual 
operating  days,  annual  number  of  missions,  mean 
mission  duration,  etc.)  to  provide  input  to  the  LSA 
process.  \ 

(2)  Maintenance  Concept— Briefly  describe 
maintenance  requirements,  considerations,  and  con¬ 
straints  in  terms  of  number  of  skill  level  of 
maintenance  personnel,  number  of  inventory  items, 
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maintenance  environment,  levels  of  maintenance, 
operational  reliability  and  survivability  requirements, 
failure  diagnostic  techniques,  support  equipment, 
and  any  maintenance  considerations  peculiar  to  the 
system.  Identify  any  maintenance  concept  trade-offs 
to  be  performed.  Provide  sufficient  detail  (turn¬ 
around  time,  mean  time  between  maintenance,  mean 
time  to  repair,  etc.)  to  support  LSA  data  re¬ 
quirements.  Include  pertinent  information  about 
interservicing,  interim  contractor  support,  and  con¬ 
tractor  logistics  support. 

(3)  Logistics  Support  Analysis— Describe  the 
LSA  program.  Include  a  brief  description  of  LSA 
tasks  required,  the  structure  of  the  LSA  data  system, 
and  contractor— government  interrelationships  in 
the  conduct  of  LSA. 

(4)  Acquisition  Strategy— Briefly  describe  the 
procurement  approach  and  define  new  or  innovative 
contractual  approaches  for  life  cycle  costs,  logistics 
support  costs,  reliability  improvement  warranties 
(RIW),  spares  acquisition  integrated  with  production 
concept,  and  interim  contractor  support.  Also, 
describe  budget  and  funding  policies  that  are  in  addi¬ 
tion  to,  or  deviate  from,  standard  procedures,  etc. 

(5)  Test  and  Evaluation  Concept— Briefly 
describe  the  test  and  evaluation  concept  in  terms  of 
DT&E,  OT&E,  participating  organizations  (in¬ 
cluding  contractor),  and  management  relationships. 
Include  information  on  peculiar  test  requirements 
that  are  directly  related  to  the  ILS  program  (that  is, 
reliability,  maintainability,  supportability,  or  contrac¬ 
tual  requirements  related  to  a  support  cost  guarantee 
or  RIW).  Address  the  interface  between  the  LSA  data 
system  and  the  test  program. 

(6)  Other  Concepts— Briefly  describe  unique 
or  innovative  support  concepts  established  or  re¬ 
quired  to  provide  effective  logistics  support.  Do  not 
repeat  standard  support  concepts,  except  to  show 
the  interface  or  rationale  for  the  new  concept.  Briefly 
describe  any  peculiar  aspects  of  the  system,  such  as 
survivability  considerations,  technical  data,  support 
equipment,  etc.  Transportation  and  packaging  con¬ 
cepts  may  be  added,  to  describe  unique  requirements 
for  protection  and  movement  of  system  and  equipment. 

c.  Part  III— Milestone  Schedule  Charts 
(MSC): 

(1)  Use  these  charts  to  address  specific  ILS 
functions  and  to  show  the  anticipated  beginning  and 
completion  dates  for  each  task  and  event,  the  assigned 
OPR,  and  the  applicable  resource  requirements  (as  a 
minimum,  identify  OPRs  by  the  three-letter  office 
symbol). 

(2)  Use  resource  requirements  to  represent 
commitments  agreed  to  by  the  participants. 


(3)  Coordinate  the  ILS  milestones  with  all 
organizations  involved,  to  ensure  that  tasks  and 
events  are  complete,  accurate,  integrated  with  con¬ 
tractual  requirements,  and  related  to  key  “program” 
milestones. 

(4)  Do  not  include  narrative  in  Part  III  of  the 
JILSP. 

(5)  Set  up  the  first  MSC  during  the  conceptual 
phase.  During  the  full-scale  engineering  development 
(FSED),  expand  the  MSC  to  include  detailed  tasks, 
responsibilities,  and  schedules  for  providing  logistics 
support  for  the  system  or  equipment. 

(6)  Delegate  the  responsibility  for  maintaining 
current  status  of  the  MSC  to  working  level  people  in 
each  ILS  functional  area.  This  includes  tracking 
tasks  and  events,  as  well  as  reporting  progress. 

(7)  Set  up  procedures  to  ensure  that  it 
becomes  apparent  that  a  milestone  will  not  be  met  or 
when  new  program  direction  or  guidance  impacts  the 
functional  area. 

(8)  Set  up  and  maintain  management  visibility 
of  all  hardware,  down  to  and  including  all 
recoverable  assemblies. 

(9)  MSCs  should  normally  be  prepared  for 
each  of  the  functional  areas  identified  below, 
although  MSCs  for  a  specific  program  or  project  can 
be  tailored  by  the  ILSO,  as  approved  by  the  PM. 
MSCs  for  the  ILS  elements  should  be  developed 
using  network  analysis.  Representative  examples  of 
the  types  of  tasks  and  events  that  should  be  con¬ 
sidered  for  tracking  through  MSCs  are  listed  follow¬ 
ing  each  subparagraph  heading.  Individual  MSCs 
must  reflect  the  support  to  be  provided  by  all  par¬ 
ticipating  services  and  agencies. 

(a)  Reliability  and  Maintainability  (R&M) 
Interface— Set  up  R&M  program  plans;  conduct 
R&M  tradeoff  studies;  conduct  R&M  evaluation; 
define  R&M  design  guidelines  and  requirements, 
failure  mode  and  effects  analysis  (FMEA),  and  task 
and  skill  analysis;  implement  the  LSA  program;  ap¬ 
prove  LSA  plan;  provide  government  inputs  to  the 
contractor;  set  up  logistics  design  appraisal  schedule; 
etc. 

(b)  Maintenance  Planning— Attain  re¬ 
quired  maintenance  capability  for  organizational  and 
intermediate  repair;  do  the  depot  maintenance 
source  of  repair  decision  tree  analysis  and  interserv¬ 
ice  screening;  establish  depot  maintenance  capa¬ 
bility;  identify  requirements  for  interim  contractor 
support;  identify  facilities  and  training  requirements; 
ensure  that  provisions  are  made  for  survivability,  cor¬ 
rosion  prevention,  spectrometric  oil  analysis, 
nondestructive  inspection,  structural  integrity,  built- 
in  test  equipment,  built-in  test  and  performance 
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monitoring,  and  maintenance  activation  planning,  etc. 

(c)  Support  Equipment— Identify,  pro¬ 
gram,  and  deliver  preoperational  support  equipment 
(SE);  conduct  SE  guidance  conference;  set  up  re¬ 
quirements  for  SE,  software,  rights  in  data  and  com¬ 
puter  resources,  data,  and  documentation;  review  SE 
recommendations  data  (SERDS);  identify,  quantify, 
and  program  all  operational  SE;  acquire  and  deliver 
SE  on  contract;  identify,  quantify,  and  program  or 
acquire  all  logistics  support  elements  needed  to 
maintain  the  SE  (spares,  technical  data,  calibration 
requirements,  etc.). 

(d)  Supply  Support— Identify  and  program 
spares  required  for  preoperational  support;  program 
disposition  of  residual  preoperational  assets;  set  up 
provisioning  plans;  identify  requirement  for  interim 
contractor  support;  determine  requirement  for  and 
conduct  provisioning  guidance  conference;  identify 
long  leadtime  items;  identify,  quantify,  and  program 
availability  of  spare  and  repair  parts;  etc. 

(e)  Packaging,  Handling,  and  Transporta¬ 
tion-Set  up  packaging,  handling,  and  transporta¬ 
tion  concepts  and  criteria;  identify  packaging,  handl¬ 
ing,  and  transportation  supply  requirements;  review 
transportability  reports’  review  and  evaluate  data 
processed  through  the  Container  Design  Retrieval 
System;  develop  transportation  plan;  review  detailed 
packaging  data;  develop  test  support  criteria;  identify 
storage  needs  for  hazardous  materials,  conventional 
munitions,  etc. 

(0  Technical  Data— Prepare  an  engineer¬ 
ing  data  management  plan;  define  the  engineering 
data  required  for  specific  organic  functions;  identify 
the  tasks  to  be  done  during  each  program  phase;  set 
up  plans  and  schedules  for  in-process  reviews  of 
engineering  data;  identify  review  team  composition 
and  responsibilities;  conduct  reviews;  set  up 
schedules  for  delivery  of  engineering  data:  prepare 
technical  order  publication  plan;  identify  re¬ 
quirements  for  preliminary  manuals,  for  operation 
and  maintenance  of  all  systems  and  equipments; 
prepare  validation  and  verification  plans;  verify  and 
validate  technical  orders;  print  and  send  out 
technical  orders;  etc. 

(g)  Facilities— Prepare  facility  require¬ 
ments  plan;  conduct  surveys  to  determine  re¬ 
quirements  for  new  or  modified  preoperational, 
operational,  training,  depot,  or  simulator  facilities; 
budget  for  and  construct  facilities;  etc. 

(h)  Manpower  Requirements  and  Person¬ 
nel-Insert  a  matrix  of  quantitive  requirements  for 
each  function  established  for  operation,  supply,  and 
maintenance  of  the  equipment,  the  personnel  skill 
code  (MOS/AFSC/NEC)  and  the  job  title  required. 


Include  whether  military,  government,  civilian,  or 
contractor;  describe  the  qualitative  personnel  skill 
requirements  for  operation  and  support;  plan  for 
operating/support  commands  to  acquire  personnel. 

(i)  Training  and  Training  Support— Initi¬ 
ate  government  and  contractor  training;  conduct 
follow-on  crew  and  logistics  support  personnel  train¬ 
ing;  identify,  quantify,  and  program  all  required  crew 
and  maintenance  training  equipment,  including 
simulators,  as  well  as  the  logistics  support  elements 
required. 

O')  Logistics  Support  Resource  Funds— Pre¬ 
pare  budget  inputs  for  spares,  common  support 
equipment,  preoperational  support,  stock  fund,  etc. 

(k)  Logistics  Support  Management  Infor¬ 
mation-Take  part  in  program  reviews  and  logistics 
assessment  reviews;  conduct  planning  and  guidance 
conferences;  review  and  revise  the  JILSP;  determine 
management  data  requirements,  including  test  data 
feedback  to  LSA  and  provisioning  activities;  etc. 

(l)  Computer  Resources  Support — Deliver 
computer  resources  development  plan;  review  com¬ 
puter  program  configuration  item  (CPCI)  re¬ 
quirements;  determine  software  needs,  to  meet 
system  R&M  requirements;  deliver  Part  I  specifica¬ 
tion;  form  a  CRWG;  publish  the  CRISP;  etc.  NOTE: 
This  entry  is  deleted  after  publication  of  the  CRISP 
and  a  cross-reference  to  the  CRISP  is  entered 
herein. 

(m)  Energy  Management— Conduct  trade¬ 
off  studies  and  analyses;  develop  energy  conservation 
goals;  perform  modifications;  etc. 

(n)  Survivability— Include  logistics  inter¬ 
face  with  nuclear  hardness  assurance  planning  and 
other  special  logistics  considerations,  to  be  included 
in  logistics  planning,  to  ensure  design  integrity  of 
special  survivability  features  throughout  the  system 
life  cycle. 

(o)  Test  and  Evaluation— Set  critical  ques¬ 
tions,  issues,  and  DT&E  and  OT&E  logistics  objec¬ 
tives  and  requirements  for  the  test  and  evaluation 
master  plan;  set  logistics  test  requirements;  identify 
representation  for  test  planning  work  group.  NOTE: 
This  section  addresses  tasks  and  events  for  program 
level  test  planning  documents.  Detailed  test  tasks 
and  events,  required  to  support  the  planning  and 
management  of  individual  ILS  functions,  will  be  ad¬ 
dressed  under  the  sections  for  each  function. 

(p)  Modification  Planning— Document 
modification  and  kit  proofing  requirements;  set  up 
kit  production  rates  compatible  with  proposed 
modification  schedules;  send  modification  proposal 
analysis;  coordinate  with  the  proper  support  activity 
and  configuration  control  board  representative;  im- 
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plement  modification  schedule;  evaluate  effec¬ 
tiveness  of  modifications,  etc. 

(q)  Special  Considerations— Set  up  re¬ 
quirements  for  contractor  operations  and  support 
cost  estimates  and  reporting;  identify  security 
assistance  program  requirements  and  site  and  depot 
activations;  set  up  specific  tradeoffs  to  be  carried  out 
by  the  contractor;  set  up  requirements  for  the  con¬ 
tractor  to  identify  and  submit  the  supply  support 
plan,  before  the  test;  develop  contractual  re¬ 
quirements  for  support  cost  guarantee  or  RIW; 
develop  a  plan  for  assessing  the  accomplishment  of 
hardware  and  support  system  goals;  develop  a 
verification  and  improvement  program,  site  and 
depot  activation,  deficiency  reporting  (for  example, 
specific  routing  and  action  channels  for  improvement 
or  deficiency  correction,  material  deficiency  report¬ 
ing),  and  other  special  considerations  not  included  in 
one  of  the  above  categories. 


/ 
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APPENDIX  E 
Definition  of  Terms 


Acquisition.  The  process  for  obtaining  systems, 
equipment,  or  modifications  to  existing  inventory 
items. 

Acquisition  Life  Cycle.  Normally,  this  consists  of 
four  phases,  with  each  preceded  by  a  milestone  deci¬ 
sion.  Described  below  is  a  normal  acquisition  path, 
not  a  prescribed  one  that  all  programs  must  follow.  A 
program  may  skip  a  phase  or  have  program  elements 
in  any  or  all  phases. 

a.  Program  Initiation ;  Concept  Exploration 
Phase  (Phase  0).  The  identification  and  exploration 
of  alternative  solutions  or  solution  concepts  to  satisfy 
a  validated  need,  usually  through  the  use  of  contracts 
with  competent  industry  and  educational  institutions. 
This  phase  requires  the  active  involvement  of  all  par¬ 
ticipating  commands  to  identify  the  candidate  solu¬ 
tions  and  their  characteristics.  One  or  more  of  the 
selected  candidate  solutions  is  then  approved  for 
entry  into  the  Demonstration  and  Validation  Phase. 

b.  Requirement  Validation;  Demonstration  and 
Validation  Phase  (Phase  I).  The  period  when  selected 
candidate  solutions  are  refined  through  extensive 
study  and  analyses;  hardware  development,  if  appro¬ 
priate;  tests;  and  evaluations.  The  objective  is  to  vali¬ 
date  one  or  more  of  the  selected  solutions  and  pro¬ 
vide  a  basis  for  deciding  whether  to  proceed  into 
Full-Scale  Development. 

c.  Program  Go-Ahead;  Full-Scale  Development 
Phase  (Phase  II).  The  period  when  the  system  and 
the  principal  items  necessary  for  its  support  are  de¬ 
signed,  fabricated,  tested  and  evaluated.  The  in¬ 
tended  output  is,  as  a  minimum:  a  preproduction  sys¬ 
tem  that  closely  approximates  the  final  product;  the 
documentation  needed  to  enter  the  production 
phase;  and  the  test  results  that  show  the  product  will 
meet  the  requirements.  This  phase  includes  the  pro¬ 
curement  of  long  lead  production  items  and  limited 
production  for  OT&E. 

d.  Production  and  Deployment;  Production  and 
Deployment  Phase  (Phase  III). 

(1)  Production  Phase.  The  period  from  produc¬ 
tion  approval  until  the  last  system  is  delivered  and  ac¬ 
cepted.  The  objective  is  to  efficiently  produce  and  de¬ 
liver  effective  and  supportable  systems  to  the  operat¬ 
ing  units.  This  includes  the  production  of  all  princi¬ 
pal  and  support  equipment. 


(2)  Deployment  Phase.  The  period  encompass¬ 
ing  the  process  of  uniting  facilities,  hardware  and 
software,  personnel  and  procedural  publications;  and 
delivering  an  acceptable  integrated  system  to  the 
using  and  supporting  commands.  This  overlaps  the 
production  phase. 

Acquisition  Logistics.  The  process  of  systematically 
identifying  and  assessing  logistics  alternatives; 
analyzing  and  resolving  ILS  deficiencies;  and  manag¬ 
ing  ILS  throughut  the  acquisition  process. 

Acquisition  Program.  A  directed  effort  funded 
either  through  procurement  appropriations;  through 
the  Security  Assistance  Program;  or  through  the  Re¬ 
search,  Development,  Test  and  Evaluation  appropri¬ 
ation  with  the  goal  of  providing  a  new  or  improved 
capability  in  response  to  a  validated  need.  An  acqui¬ 
sition  program  may  include  either  development  or 
procurement  of  system,  subsystems,  equipment,  mu¬ 
nitions,  or  modifications  to  them,  as  well  as  support¬ 
ing  equipment,  systems,  projects,  and  studies.  Ex¬ 
cluded  from  this  definition  and  from  this  regulation 
are  the  general  purpose,  commercially  available 
automatic  data  processing  assets  defined  under  OMB 
Circular  A-71  and  DOD  Directives  5105.55,  4160.19, 
and  5100.40. 

Acquisition  Risk.  The  chance  that  some  element  of 
an  acquisition  program  produces  an  unintended  re¬ 
sult  with  adverse  effect  on  system  effectiveness,  suita¬ 
bility,  cost,  or  availability  for  deployment. 

Availability.  A  measure  of  the  degree  to  which  an 
item  is  in  an  operable  and  commitable  state  at  the 
start  of  a  mission  when  the  mission  is  called  for  at  an 
unknown  (random)  time. 

Built-In  Test  Equipment  (BITE).  Any  device  per¬ 
manently  mounted  in  the  prime  equipment,  and  used 
for  the  express  purpose  of  testing  the  prime  equip¬ 
ment,  either  independently  or  in  association  with  ex¬ 
ternal  test  equipment. 

Combat  System  Test  Installation.  A  collection  of 
subsystems  including  weapons,  sensor,  and  informa¬ 
tion  processing  equipment,  together  with  their  inter¬ 
faces  installed,  for  the  purposes  of  early  testing 
before  the  availability  of  a  first  production  item,  at  a 
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fixed  or  mobile  test  facility  designed  to  simulate  the 
essential  parts  of  the  production  item. 

Contract.  An  agreement  between  two  or  more  com¬ 
petent  parties,  in  the  proper  form,  on  a  legal  subject- 
matter,  for  a  legal  consideration. 

Contract  Definition.  A  funded  effort,  normally  by 
two  or  more  competing  contractors,  to  establish  spe¬ 
cifications,  to  select  technical  approaches,  to  identify 
high-risk  areas,  and  to  make  cost  and  production 
time  estimates  for  developing  large  weapons  systems. 

Contract  Work  Breakdown  Structure  (CWBS). 

The  complete  WBS  for  a  contract,  developed  and 
used  by  a  contractor  within  the  guidelines  for  MIL- 
STD  881A,  and  in  accordance  with  the  contract  work 
statement. 

Cost/Schedule  Control  Systems  Criteria 
(C/SCSC).  Criteria  used  to  evaluate  the  effectiveness 
of  contractors;  internal  systems.  The  C/SCSC  do  not 
require  any  data  to  be  reported  to  the  government, 
but  do  provide  for  access  to  data  needed  to  evaluate 
the  system  and  monitor  its  operation  during  the  life 
of  the  contract. 

Critical  Issues.  Those  aspects  of  a  system’s  capabil¬ 
ity,  either  operational,  technical,  or  other,  that  must 
be  questioned  before  a  system’s  overall  worth  can  be 
estimated,  and  that  are  of  primary  importance  to  the 
decision  authority  in  reaching  a  decision  to  allow  the 
system  to  advance  into  the  next  acquisition  phase. 

Decision  Coordinating  Paper/Integrated  Pro¬ 
gram  Summary  (DCP/IPS).  Used  at  Milestone  II 
(and  Milestone  III  if  the  SecDefs  decision  is  re¬ 
quired).  Summarizes  the  DOD  components  acquisi¬ 
tion  planning  for  the  system’s  life  cycle  and  provides 
a  management  overview  of  the  program. 

Defense  Acquisition  Executive  (DAE).  The  princi¬ 
pal  advisor  and  staff  assistant  to  the  Secretary  of  De¬ 
fense  and  the  focal  point  in  OSD  for  System  Acquisi¬ 
tions.  The  DAE  is  USDRE  per  DOD  Directive 
5000.1. 

Defense  System  Acquisition  Review  Council 
(DSARC).  An  advisory  body  to  the  Secretary  of 
Defense  on  major  system  acquisition.  The  Council 
members  are  the  OSD  staff  principals  plus  service 
secretaries. 

Depot  Maintenance  Interservicing.  Use  of  a  single 
service’s  depot  maintenance  capability,  instead  of 
each  service  developing  an  independent  capability. 
This  technique  is  part  of  the  Standard  Integrated 
Support  Management  System  (SISMS). 


Deputy  Program  Manager  for  Logistics  (DPML). 

An  experienced  logistician  who  is  assigned  to  a  major 
program  office  to  manage  ILS. 

Design  to  Cost.  An  acquisition  management  tech¬ 
nique  used  to  control  a  product’s  life-cycle  cost.  The 
technique  embodies  the  establishment  of  “design-to- 
cost”  goals  for  the  new  product  early  in  the  acquisi¬ 
tion  effort.  The  goals  usually  relate  to  segments  of 
the  product’s  life-cycle  cost;  for  example,  RDT&E, 
production,  operation,  and  support.  The  technique 
applies  only  to  acquisition  or  modification  programs 
that  involve  design  effort.  Where  a  dollar  figure  can¬ 
not  be  fixed,  suitable  non-dollar  parameters  may  be 
used  (for  example,  mean  time  between  failures,  gal¬ 
lons  per  hour,  numbers  of  personnel,  etc.). 

Designated  Line  Authority.  Management  person¬ 
nel  responsible  for  making  major  decisions  during 
the  acquisition  of  weapon  systems.  They  typically  in¬ 
clude  the  SECDEF,  Service  Secretary  or  Competent 
Commander. 

Development  Test  and  Evaluation.  That  test  and 
evaluation  conducted  to  assist  the  engineering  de¬ 
sign  and  development  process  and  verify  attainment 
of  technical  performance  specifications  and  objec-- 
fives. 

Development  Test  I  (DT I).  This  test  is  conducted 
early  in  the  development  cycle,  normally  during  the 
validation  phase.  Components,  subsystems,  or  the 
entire  system  are  examined  to  determine  whether  the 
system  is  ready  for  full-scale  development.  State-of- 
the-art  technology  is  addressed  to  DT  I  (Army). 

Development  Test  II  (DT  II).  This  test  provides  that 
technical  data  necessary  to  assess  whether  the  sys¬ 
tem  is  ready  for  low-rate  initial  or  full-scale  produc¬ 
tion.  It  measures  the  technical  performance  and  safe¬ 
ty  characteristics  of  the  item  and  evaluates  its  associ¬ 
ated  tools;  test  equipment,  training  package,  and 
maintenance  test  package  as  described  in  the  devel¬ 
opment  plan.  DT  II  addresses  accomplishments  of 
engineer  design  goals  (Army). 

DOD  Planning/Programming:  Budgeting  System 
(PPBS).  An  integrated  system  for  the  establishment, 
maintenance,  and  revision  of  the  FYDP  and  the 
DOD  budget. 

Evaluation  Criteria.  Standards  by  which  achieve¬ 
ment  of  required  operational  effectiveness/suitability 
characteristics,  or  resolution  of  technical  or  opera¬ 
tional  issues  may  be  judged.  At  Milestone  II  and  be¬ 
yond,  evaluation  criteria  must  include  quantitative 
goals  (the  desired  value)  and  thresholds  (the  value 
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beyond  which  the  characteristic  is  unsatisfactory). 

Five-Year  Defense  Program  (FYDP).  The  Five- 
Year  Defense  Program  summarizes  all  approved  pro¬ 
grams  of  the  entire  Department  of  Defense.  Re¬ 
sources  or  inputs  required  for  5  years  are  combined 
with  military  outputs  or  programs  for  the  same 
period.  The  FYDP  is  expressed  in  terms  of  pro¬ 
grams,  program  elements,  and  resource  categories: 
(a)  mission  operations;  (b)  administration;  (c)  sup¬ 
ply  operations;  (d)  maintenance  or  material; 
(e)  property  disposal;  (f)  medical  operations; 
(g)  base  services;  (h)  maintenance  of  Real  Property; 
(i)  utility  operations;  (j)  father  engineering  support; 
(k)  minor  construction;  (1)  personal  support.  Sub¬ 
functional  categories  are  a  finer  grouping  within  the 
functional  category  grouping.  They  are  used  to  ac¬ 
cumulate  expenses  separately  for  various  functions 
encompassed  by  a  single  functional  category. 

Government  Furnished  Equipment  (GFE).  Items 
in  the  possession  of,  or  acquired  by,  the  government 
and  delivered  to  or  otherwise  made  available  to  the 
contractor. 

Handling.  The  coordination  and  integration  of  all 
operations  embracing  packaging,  protection,  and 
movement  of  material  by  available  equipment  for 
short  distances. 

Implementing  Command.  The  command  responsi¬ 
ble  for  the  acquisition  and/or  modification  of  the 
system  (AF). 

Initial  Operational  Test  and  Evaluation  (IOT&E). 

That  portion  of  Operational  Test  and  Evaluation 
conducted  prior  to  the  Milestone  III  decision. 

Integrated  Logistics  Support  (ILS).  A  unified  and 
interactive  approach  to  the  management  and  tech¬ 
nical  activities  necessary  to: 

a.  Cause  support  considerations  to  influence  both 
requirements  and  design. 

b.  Define  support  requirements  that  are  optimally 
related  to  the  design  and  to  each  other. 

c.  Acquire  the  required  support. 

d.  Provide  for  the  required  support  in  the  opera¬ 
tional  phase  at  minimum  cost. 

Integrated  Logistics  Support  Elements.  Principal 
logistics  elements  that  must  be  properly  integrated  to 
achieve  economical  and  effective  support  of  a  system 
or  equipment  throughout  its  life  cycle.  (See  DODI 
5000.39). 

Integratead  Logistics  Support  Manager  (ILSM). 

An  experienced  logistician  who  is  assigned  to 
manage  ILS  for  programs  not  designated  as  major 
programs. 


Integrated  Logistics  Support  Office  (ILSO).  An 

ILS  office  within  a  program  office. 

Integrated  Logistics  Support  Plan  (ILSP).  An  Air 

Force  management  plan  developed  and  used  by  the 
program  manager  and  the  DPML  or  ILSM,  to  man¬ 
age  the  ILS  process.  This  includes  the  horizontal  in¬ 
tegration  of  the  ILS  elements  (that  is,  with  each 
other),  as  well  as  their  vertical  integration  into  the 
various  aspects  of  program  planning,  engineering, 
designing,  testing,  evaluating,  and  during  production 
and  operation.  It  also  includes  the  integration  of  sup¬ 
port  elements  with  the  mission  elements  of  a  system 
throughout  its  life  cycle,  and  is  updated  as  the  pro¬ 
gram  evolves. 

Integrated  Program  Summary  (IPS).  Summarizes 
the  DOD  Component’s  acquisition  planning  for  the 
system’s  life  cycle  and  provides  a  management  over¬ 
view  of  the  program. 

Integrated  Support  Plan  (ISP).  An  iterative  docu¬ 
ment  prepared  by  a  contractor  for  the  acceptance 
and  approval  of  the  acquisition  activity.  It  describes 
the  contractor’s  plan  for  managing  the  contractual 
ILS  program,  for  complying  with  the  specific  contrac¬ 
tual  ILS  requirements,  and  for  planning  any  opera¬ 
tional  support  functions  assigned  to  the  contractor. 

Interim  Contractor  Support  (ICS).  A  cost-effective 
logistics  support  alternative  for  a  major  system  of  a 
high  cost  or  risk  Class  V  modification.  It  allows  the 
service  to  deter  investment  in  all  or  part  of  the  sup¬ 
port  resources  (spares,  technical  data,  support  equip¬ 
ment,  training  equipment,  etc.)  and  to  use  contractor 
support  while  the  organic  capability  is  being  phased 
in. 

Justification  for  Major  System  New  Start 
(JMSNS).  Major  system  new  starts  are  considered  in 
the  OSD  Program  Objective  Memorandum  (POM)  re¬ 
view  on  the  basis  of  justifications  provided  by  DOD 
Components.  These  justifications  are  prepared  as  a 
document  called  the  JMSNS. 

JT&E  Program.  An  OSD  program  for  JT&E,  spon¬ 
sored  by  the  DDTE,  structures  to  evaluate  or  provide 
information  on  system  performance,  technical  con¬ 
cepts,  system  requirements  or  improvements,  subsys¬ 
tems  interoperability,  improving  or  developing  test¬ 
ing  methodologies,  or  for  force  structure  planning, 
doctrine  or  procedures. 

Life-Cycle  Cost  (LCC).  The  total  cost  of  an  item  or 
system  over  its  full  life.  It  includes  the  cost  of  acquisi¬ 
tion,  ownership  (operation,  maintenance,  support, 
etc.),  and  disposal.  To  be  meaningful,  an  expression 
of  LCC  must  be  placed  in  context  with  the  cost  ele- 
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ments  included,  period  of  time  covered,  assumptions 
and  conditions  applied,  and  whether  it  is  intended  as 
a  relative  comparison  or  an  absoluste  expression  of 
cost  effects. 

Logistics  Engineering .  This  function  provides  in¬ 
puts  to  the  systems  engineering  process  in  all  acqui¬ 
sition  phases.  In  general,  these  inputs  are  the  sup¬ 
port  environment  descriptors  and  constraints.  This 
function  uses  the  technical  data  developed  by  the  sys¬ 
tems  engineering  process  to  refine  support  plans, 
concepts,  and  requirements  for  a  system’s  support  in 
deployment  and  operational  use.  The  logistics  engi¬ 
neering  function  is  a  part  of  the  mainstream  engi¬ 
neering  effort,  to  develop  and  achieve  a  suitable  and 
cost-effective  system.  This  function  uses  the  detailed 
drawings  that  are  prepared  by  design  engineering  to 
develop  the  specific  requirements;  that  is,  to  develop 
such  specific  support  items  as  tools,  test  equipment, 
personnel  skills,  and  maintenance  procedures. 

Logistics  Support  Analysis  (LSA).  An  analytical  lo¬ 
gistics  effort  within  the  systems  engineering  process 
to  identify,  define,  analyze,  quantify,  and  process  lo¬ 
gistics  support  requirements.  The  logistics  support 
analysis  record  (LSAR)  is  the  source  of  validated,  in¬ 
tegrated,  and  design-related  data  for  an  acquisition 
program.  There  are  four  functions  of  the  LSA  proc¬ 
ess: 

a.  To  identify  the  qualitative  and  quantitative  lo¬ 
gistics  considerations. 

b.  To  influence  the  system  and  equipment  design 
for  logistics  considerations. 

c.  To  communicate  requirements  and  provide  an 
integrating  influence. 

d.  To  assess  the  achievement  of  logistics  objec¬ 
tives.  NOTE:  LSA  is  described  in  MIL-STD-1388-1, 
and  MIL-STD-1388-2. 

Logistics  Supportability.  The  degree  to  which  the 
planned  logistics  (including  test  equipment,  spares 
and  repair  parts,  technical  data,  support  facilities, 
and  training)  and  manpower  meet  system  availability 
and  wartime  usage  requirements. 

Long  Lead  Items.  Those  components  of  a  system  or 
piece  of  equipment  that  take  the  longest  time  to  pro¬ 
cure  and,  therefore,  may  require  an  early  commit¬ 
ment  of  funds  in  order  to  meet  acquisition  schedules. 

Maintainability.  The  ability  of  an  item  to  be  re¬ 
tained  in  or  restored  to  specified  condition  when 
maintenance  is  performed  by  personnel  having  speci¬ 
fied  skill  levels,  using  prescribed  procedures  and 
resources,  at  each  prescribed  level  of  maintenance 
and  repair. 


Major  System  Acquisition.  A  system  acquisition 
program  designated  by  the  Secretary  of  Defense  to 
be  of  such  importance  and  priority  as  to  require  spe¬ 
cial  management  attention  based  on  the  criteria  in 
the  DOD  Directive  5000.1 

Memorandum  of  Agreement  (MOA).  An  agree¬ 
ment  between  a  program  manager  and  a  Contract 
Administration  Office  (CAO),  establishing  the  scope 
of  responsibility  of  the  CAO  with  respect  to  the 
C/SCSC  surveillance  functions  and  objectives. 

Memorandum  of  Understanding  (MOU).  An 

agreement  between  a  contractor  and  a  cognizant 
DOD  Administratiave  Contracting  Officer,  indicating 
the  contractor’s  intention  to  use  accepted  manage¬ 
ment  control  systems  on  future  contracts  which  re¬ 
quire  compliance  with  the  C/SCSC. 

Military  Operational  Requirements.  The  formal 
expression  of  a  military  need,  response  to  which  re¬ 
sults  in  development  or  acquisition  of  items,  equip¬ 
ment,  or  systems. 

Mission  Element.  A  segment  of  a  mission  area 
critical  to  the  accomplishment  of  the  mission-area 
objectives  and  corresponding  to  a  recommendation 
for  a  major  -system  capability  as  determined  by  a 
DOD  Component. 

Multiservice  T&E.  T&E  conducted  by  two  or  more 
DOD  Components  for  systems  to  be  acquired  by 
more  than  one  DOD  Component,  or  for  a  DOD  Com¬ 
ponent’s  systems  that  have  interfaces  with  equipment 
of  another  DOD  Component. 

Operating  and  Support  Cost.  Those  resources  re¬ 
quired  to  operate,  and  support  (O&S)  a  system,  sub¬ 
system,  or  a  major  component  during  its  useful  life  in 
the  operational  inventory. 

Operational  Effectiveness.  The  overall  degree  of 
mission  accomplishment  of  a  system  used  by  repre¬ 
sentative  personnel  in  the  context  of  the  organiza¬ 
tion,  doctrine,  tactics,  threat  (including  counter¬ 
measures  and  nuclear  threats)  and  environment  in 
the  planned  operational  employment  of  the  system. 

Operational  Suitability.  The  degree  to  which  a  sys¬ 
tem  can  be  satisfactorily  placed  in  field  use,  with  con¬ 
sideration  being  given  to  availability,  compatibility, 
transportability,  interoperability,  reliability,  wartime 
usage  rate,  maintainability,  safety,  human  factors, 
manpower  supportability,  logistic  supportability,  and 
training  requirements. 

Operational  Test  and  Evaluation  (OTE).  That  test 
and  evaluation  conducted  to  estimate  a  system’s  op- 
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erational  suitability,  as  well  as  the  need  for  any  modi¬ 
fications.  It  is  accomplished  by  operational  and  sup¬ 
port  personnel  of  the  types  and  qualifications  ex¬ 
pected  to  use  and  maintain  the  system  when  de¬ 
ployed  and  is  conducted  in  as  realistic  an  operational 
environment  as  possible. 

Packaging.  The  process  and  procedures  used  to 
protect  material.  It  includes  cleaning,  drying,  pre¬ 
serving,  packaging,  marking,  and  utilization. 

Pilot  Production  Item.  An  item  produced  from  a 
limited  production  run  to  demonstrate  the  capability 
to  mass  produce  the  item  for  operational  use. 

Pre-Production  Prototype.  An  article  in  final  form 
employing  standard  parts,  representative  of  articles 
to  be  produced  subsequently  in  a  production  line. 

Producibility.  The  relative  ease  of  producing  an 
item  or  system  which  is  governed  by  the  characteris¬ 
tics  and  features  of  a  design  that  enable  economical 
fabrication,  assembly,  inspection,  and  testing  using 
available  production  technology. 

Production  Engineering.  The  application  of  design 
and  analysis  techniques  to  produce  a  specified  pro¬ 
duct.  Included  are  the  functions  of  planning,  specify¬ 
ing,  and  coordinating  the  application  of  required  re¬ 
sources;  performing  analyses  of  producibility  and 
production  operations,  processes,  and  systems;  ap¬ 
plying  new  manufacturing  methods,  tooling,  and 
equipment;  controlling  the  introduction  of  engineer¬ 
ing  changes;  and  employing  cost-control  techniques. 

Production  Feasibility.  The  likelihood  that  a 
system  design  concept  can  be  produced  using  exist¬ 
ing  production  technology  while  simultaneously 
meeting  quality,  production  rate,  and  cost  require¬ 
ments. 

Production  Management.  The  effective  use  of  re¬ 
sources  to  produce  on  schedule  the  required  number 
of  end  items  that  meet  specified  quality,  perform¬ 
ance,  and  cost. 

Production  Readiness.  The  state  or  condition  of 
preparedness  of  a  system  program  to  proceed  into 
production.  A  system  is  ready  for  production  when 
the  completeness  and  producibility  of  the  production 
design  and  the  managerial  and  physical  preparations 
necessary  for  initiating  and  sustaining  a  viable  pro¬ 
duction  effort  have  progressed  to  the  point  where  a 
production  commitment  can  be  made  without  incur¬ 
ring  unacceptable  risks  that  thresholds  of  schedule, 
performance,  cost,  or  other  established  criteria  will 
be  breached. 


Production  Readiness  Review.  A  formal  examina¬ 
tion  of  a  program  to  determine  if  the  design  is  ready 
for  production,  production  engineering  problems 
have  been  resolved,  and  the  producer  has  accom¬ 
plished  adequate  planning  for  the  production  phase. 

Program  Decision  Memorandum  (PDM).  The  Sec¬ 
retary  of  Defense’s  approval  of  the  Service’s  Program 
Objective  Memorandum  with  tentative  specific 
guidance. 

Program  Evaluation  Review  Technique  (PERT). 

A  technique  for  management  of  a  program  through 
to  completion  by  constructing  a  network  model  of  in¬ 
tegrated  activities  and  events  and  periodically  evalu¬ 
ating  the  time/cost  implications  of  progress. 

Program  Management  Directive  (PMD).  The  offi¬ 
cial  HQ  USAF  management  directive  used  to  provide 
direction  to  the  implementing  and  participating  com¬ 
mands  and  satisfy  documentation  requirements.  It 
will  be  used  during  the  entire  acquisition  cycle  to 
state  requirements  and  request  studies  as  well  as  ini¬ 
tiate,  approve,  change,  transition,  modify  or  termi¬ 
nate  programs.  The  content  of  the  program  manage¬ 
ment  directive,  including  the  required  HQ  USAF  re¬ 
view  and  approval  actions,  is  tailored  to  the  needs  of 
each  individual  program. 

Program  Manager  (PM).  The  individual  in  the 
DOD  chartered  to  manage  a  major  system  acquisi¬ 
tion  program. 

Program  Manager  Charter.  A  document  approved 
by  the  DOD  Component  Head  stating  the  program 
manager’s  responsibility,  authority  and  accountabil¬ 
ity  in  the  management  of  a  major  system  acquisition 
program. 

Program  Objectives  Memorandum  (POM).  A 
memorandum  in  prescribed  format  submitted  to  the 
Secretary  of  Defense  by  the  Secretary  of  a  Military 
Department  or  the  Director  of  a  Defense  Agency 
which  recommends  that  total  resource  requirements 
within  the  parameters  of  the  Secretary  of  Defense 
fiscal  guidance. 

Realistic  Test  Environment.  The  conditions  under 
which  the  system  is  expected  to  be  operated  and 
maintained,  including  the  natural  weather  and  cli¬ 
matic  conditions,  terrain  effects,  battlefield  disturb¬ 
ances,  and  enemy  threat  conditions. 

Reliability.  A  fundamental  characteristic  of  an  item 
of  material  expressed  as  the  probability  that  it  will 
perform  its  intended  function  for  a  specified  period 
of  time  under  stated  conditions. 
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Reliability,  Mission.  The  ability  of  an  item  to  per¬ 
form  its  required  functions  for  the  duration  of  a  spe¬ 
cified  mission  profile. 

Request  for  Proposal  (RFP).  Solicitation  document 
used  in  negotiated  procurement  when  the  govern¬ 
ment  reserves  the  right  to  award  without  further  oral 
or  written  negotiation.  Only  the  acceptance  of  the 
government  is  required  to  create  a  binding  contract. 
Of  course,  the  government  can  choose  to  negotiate 
further  at  its  option. 

Required  Operational  Characteristics.  System 
parameters  that  are  primary  indicators  of  the 
system’s  capability  to  be  employed  to  perform  the  re¬ 
quired  mission  functions,  and  to  be  supported. 

Required  Technical  Characteristics.  System  pa¬ 
rameters  that  are  primary  indicators  of  the  system’s 
capability  to  be  employed  to  perform  the  required 
mission  functions,  and  to  be  supported. 

Resident  Integrated  Logistics  Support  Activity 
(RILSA).  An  extension  of  the  ILS  office,  colocated  at 
the  system  or  major  equipment  contractor’s  facility. 
The  RILSA  normally  accomplishes  the  provisioning 
of  spares  and  repair  parts  and  carries  out  other 
logistics  tasks,  as  assigned  by  the  DPML. 

( Service )  System  Acquisition  Review  Council 
((S)SARC).  A  council  established  by  the  head  of  a 
military  department  as  an  advisory  body  to  him  and 
through  him  to  the  Secretary  of  Defense  on  major 
systems  acquisitions.  The  (S)SARC  is  chaired  by  the 
Secretary/Under  Secretary  fo  the  military  department 
and  is  similar  in  functional  composition,  responsibili¬ 
ties  and  operation  to  the  DSARC.  In  application  the 
term  (Service)  is  replaced  by  the  designation  of  the 
applicable  Military  Department,  i.e.,  ASARC, 
NSARC  and  AFSARC. 

Standard  Integrated  Support  Management  Sys¬ 
tem  (SIMS).  A  management  approach,  developed 
under  the  auspices  of  the  joint  logistics  commanders 
(JLC),  that  provides  a  uniform  way  to  plan  and  man¬ 
age  the  logistics  support  of  multiservice  systems  ac¬ 
quisitions. 

Statement  of  Work  (SOW).  Although  varying  widely 
in  precise  definition,  the  term  generally  covers  that 
portion  of  a  contract  which  describes  the  actual  work 
to  be  done  by  means  of  specifications  or  other  mini¬ 
mum  requirements,  quantities,  performance  dates, 
and  a  statement  of  the  requisite  quality. 


Survivability.  The  degree  to  which  a  system  is  able 
to  avoid  or  withstand  a  hostile  environment  without 
suffering  an  abortive  impairment  of  its  ability  to  ac¬ 
complish  its  designated  mission. 

System  Acquisition  Process.  The  sequence  of  ac¬ 
quisition  activities  starting  from  the  agency’s  recon¬ 
ciliation  of  its  mission  needs,  with  its  capabilities,  pri¬ 
orities  and  resources,  and  extending  through  the  in¬ 
troduction  of  a  system  into  operational  use  of  the 
otherwise  successful  achievement  of  program  objec-' 
fives. 

Systems  Concept  Paper  (SCP).  The  SCP  provides 
basic  documentation  for  use  by  DSARC  members  in 
arriving  at  a  recommendation  to  the  Secretary  of  De¬ 
fense  at  Milestone  I. 

System  Program  Office  (SPO).  The  organization 
comprised  of  technical  and  business  management 
and  administrative  personnel  assigned  full  time  to  a 
system  program  director.  The  office  may  be  aug¬ 
mented  with  additional  personnel  from  participating 
organizations. 

Test  and  Evaluation  Master  Plan.  An  overall  test 
and  evaluation  plan,  prepared  as  early  as  possible  in 
the  acquisition  process,  and  designed  to  identify  and 
integrate  objectives,  responsibilities,  resources,  and 
schedules  for  all  test  and  evaluation  to  be  accom¬ 
plished  prior  to  the  subsequent  key  decision  points. 

Transportability.  The  inherent  capability  of  ma¬ 
terial  to  be  moved  by  towing,  self-propulsion,  or  by 
railways,  highways,  waterways,  pipeline,  oceans  and 
airways,  utilizing  existing  equipment  or  equipment 
that  is  planned  for  the  movement  of  the  item  being 
considered. 

Vulnerability.  For  weapon  system  acquisition  deci¬ 
sions,  three  considerations  are  critical  in  assessing 
system  vulnerability:  susceptibility— a  system  limita¬ 
tion  or  weakness  (may  not  be  exploitable);  accessibil¬ 
ity— the  openness  of  a  system  to  exploitation  by  a 
countermeasures  technique;  and  feasibility— the 
practicality  and  probability  of  an  adversary  exploiting 
a  susceptibility  in  combat. 

Work  Breakdown  Structure  (WBS).  A  product- 
oriented  family  tree  division  of  hardware,  software, 
services,  and  other  work  tasks  that  organizes,  de¬ 
fines,  and  graphically  displays  the  product  to  be  pro¬ 
duced,  as  well  as  the  work  to  be  accomplished  to 
achieve  the  specified  product. 
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APPENDIX  F 

List  of  Joint  Service  Programs 


PROGRAM/PROJECT 

TITLE 

PROGRAM  OFFICE 
LOCATION 

LEAD 

SERVICE(S) 

PARTICIPATING 

SERVICE(S) 

CLASSIFICATION 

TYPE  (SEE  FIGURE  1-1) 

LIFE  SUPPORT  SYSTEMS 

ASD/AES 

Wright-Patterson  AFB,  OH 

Air  Force/Army 
Navy 

Air  Force/Army/Navy 

M-l 

MOBILE  AIRCRAFT 
ARRESTING  SYSTEM 

NAEC 

Lakehurst,  NJ 

Navy 

Air  Force 

S-2 

CHEMICAL/BIOLOGICAL 
DEFENSE  EQUIPMENT 

ASD/AESD 

Wright-Patterson  AFB,  OH 

Army 

Air  Force/Navy 

M-l 

MOBILE  TACTICAL 

SHELTERS 

ESD/OCR 

Hanscom  AFB,  MA 

Air  Force/Army 

Air  Force/Army/ 
Navy/Marines 

M-5 

SUPPORT  EQUIPMENT 

ASD/AEG 

Wright-Patterson  AFB,  OH 

Air  Force/Army 

Air  Force/Army/Navy 

M-5 

AIR/GROUND/SEA  LAUNCHED 
CRUISE  MISSILE 
ALCM/GLCM/SLCM 

ENGINE  &  NAV  GUIDANCE 

JCMPO 

Alexandria,  VA 

Navy 

Air  Force 

S-6 

GROUND  LAUNCHED 

CRUISE  MISSILE 

JCMPO 

Alexandria,  VA 

Navy 

Air  Force 

M-4 

MATE 

ASD/AEGB 

Wright-Patterson  AFB,  OH 

Air  Force 

Navy/Army 

S-3 

COMBAT  ID  SYS  PROGRAM 

ASD/XRQI 

Wright-Patterson  AFB,  OH 

Air  Force 

Army/Navy 

S-6 

TIPI/MAGIS/MAGIC 

ASD/DCR-I 

Air  Force 

Marines/Army 

S-6 

Hanscom  AFB,  MA 


PROGRAM/PROJECT 

TITLE 

PROGRAM  OFFICE 
LOCATION 

JOINT  TACTICAL 

FUSION  PROGRAM 

JTFPMO/Harry  Diamond  Lab 
Adelphi,  MD 

AIRBORNE  SELF¬ 
PROTECTION  JAMMER 

NAVAIRSYSCOM 
Washington,  DC 

AFSATCOM 

SD/YKA 

Los  Angeles  AFS,  CA 

FLTSATCOM 

SD/YKF 

Los  Angeles  AFS,  CA 

uses 

SD/YKD 

Los  Angeles  AFS,  CA 

SPACE  TRACK 
(ALTAIR  MOD) 

SD/YNC 

Los  Angeles  AFS,  CA 

DSP 

SD/YG 

Los  Angeles  AFS,  CA 

IONDS 

SD/YG 

Los  Angeles  AFS,  CA 

DMSP 

SD/YD 

Los  Angeles  AFS,  CA 

SATELLITE  DATA  SYS 

SD/YR 

Los  Angeles  AFS,  CA 

SATCOM 

Ft.  Monmouth,  NJ 

SPACE  DEFENSE 

SD/YN 

Los  Angeles  AFS,  CA 

NAVSTAR  GPS 

SD/YE 

Los  Angeles  AFS,  CA 

LEAD 

SERVICE(S) 

PARTICIPATING 

SERVICE(S) 

CLASSIFICATION 

TYPE  (SEE  FIGURE  1-1) 

Army 

Air/Force/Navy/Marines 

S-6 

Navy 

Air  Force 

S-6 

Air  Force 

Army/Navy 

S-2 

Navy 

Air  Force 

M-4 

OSD  (DCA) 

Air  Force/Army/Navy 

M-2 

Air  Force 

Army 

M-4 

Air  Force 

Air  Force 

S-2 

Air  Force 

Air  Force 

S-2 

Air  Force 

Navy/  Army 

S-2 

Air  Force 

Navy/Army 

S-2 

Army 

Air  Force/Marines/Navy 

S-4 

Air  Force 

Air  Force 

S-l 

Air  Force 

Army/Navy/NATO/DOT 

DMA/Marines 

S-6 

PROGRAM/PROJECT 

TITLE 

PROGRAM  OFFICE 
LOCATION 

LEAD 

SERVICE(S) 

PARTICIPATING 

SERVICE(S) 

CLASSIFICATION 

TYPE  (SEE  FIGURE  1-1 ) 

SPACE  SHUTTLE 

SD/YV 

Los  Angeles  AFS,  CA 

Air  Force 

NASA,  Navy 

S-2 

SPACE  TEST  PROGRAM 

SD/YV 

Los  Angeles  AFS,  CA 

Air  Force 

Army/Navy 

M-3 

SPACE  BOOSTERS/SPACE 
SUPPORT  PROGRAM 

SD/YV 

Los  Angeles  AFS,  CA 

Air  Force 

Navy 

S-2 

AIM-9L/M 

NAVAIRSYSCOM/PMA-259B 
Washington,  DC 

Navy 

Air  Force 

S-6 

AIM-7F/M 

NAVAIRSYSCOM/PMA-262-2 
Washington,  DC 

Navy 

Air  Force 

S-6 

HARM 

NAVAIRSYSCOM/PMA-242 
Washington,  DC 

Navy 

Air  Force 

S-6 

MAVERICK  (LASER) 

(IR) 

ASD/TAM 

Wright-Patterson  AFB,  OH 

Air  Force 

Navy/Marines 

S-6 

AMRAAM 

AD/YM 

Eglin  AFB,  FL 

Air  Force 

Navy 

S-6 

MULTIPLE  STORES 

EJECTOR  RACK  (MSER) 

Munitions  SPO  (SD-3) 

Eglin  AFB,  FL 

Air  Force 

Navy 

S-6 

NAVAIRSYSCOM/AIR-541 
Washington,  DC 

FUEL  AIR  EXPLOSIVE 
(FAE  II) 

NA  VAI RS  YSCOM/AIR-54 1 
Washington,  DC 

Navy 

Air  Force 

S-6 

Munition  SPO  (SD-3) 
Eglin  AFB,  FL 


PROGRAM/PROJECT 

TITLE 


PROGRAM  OFFICE 
LOCATION 


AIR  INFLATABLE 

Munitions  SPO  (SD-3) 

RETARDER  (AIR) 

Eglin  AFB,  FL 

NAVAIRSYSCOM/AIR  541 
Washington,  DC 

PMU-139/B 

BOMB  FUZE 

NAVAIRSYSCOM/AIR-541 
Washington,  DC 

Munitions  SPO  (SD-3) 
Eglin  AFB,  FL 

RANGE  IMPROVEMENT/ 
ACMI 

AD 

Eglin  AFB,  FL 

TRI-TAC 

T) 

it* 

DOD  TRI-TAC  Office 

Ft.  Monmouth,  NJ 

DEB 

ESD 

Hanscom  AFB,  MA 

NEXRAD 

ESD 

Hanscom  AFB,  MA 

wsc 

ESD 

Hanscom  AFB,  MA 

TRW 

ESD 

Hanscom  AFB,  MA 

IWRS 

BIGEYE  WEAPON  SYS 

ESD 

Hanscom  AFB,  MA 

NAVAIRSYSCOM 
Washington,  DC 

Munitions  SPO 

Eglin  AFB,  FL 

BIGEYE  WEAPON  SYS 


LEAD 

SERVICE(S) 

Air  Force 

Navy 

Air  Force 

Air  Force/Army 

Air  Force 

NOAA/NWS  (DOC) 
NOAA  (DOC) 

Air  Force 

NOAA  (DOC) 

Navy 


PARTICIPATING  CLASSIFICATION 

SERVICE(S)  TYPE  (SEE  FIGURE  1-1) 

Navy  S-6 


Air  Force 

S-6 

Navy 

M-4 

Navy/MC 

M-2 

tr 

Army/Navy 

S-3 

Air  Force/NWS  (DOC) 

FAA  (DOT) 

S-6 

Air  Force/NO AA  (DOC) 

M-4 

Army 

M-5 

Navy 

M-4 

Air  Force/NOAA  (DOC) 

S-5 

Air  Force 

S-3 

PROGRAM/PROJECT 

TITLE 

PROGRAM  OFFICE 
LOCATION 

LEAD 

SERVICE® 

PARTICIPATING 
SERVICE (S) 

CLASSIFICATION 
TYPE  ( SEE  FIGURE 

GATOR 

Munitions  SPO  (AD/SDS) 
Eglin  AFB,  FL 

Air  Force 

Navy/Army 

M-l 

ARRADCOM/OPOSA 
Dover,  NJ 

NAVAIRSYSCOM 
Washington,  DC 

MRASM 

JCMPO 

Washington,  DC 

Navy 

Air  Force 

5-6  &  M-2 

AD/SD-5 

Eglin  AFB,  FL 

DCS/SYSTEMS 

JOINT  SERVICE  PROGRAMS 

E-3A 

ESD 

Hanscom  AFB.  MA 

Air  Force 

Navy 

M-5 

JTIDS 

ESD 

Hanscom  AFB,  MA 

Air  Force 

Navy/  Army 

S-6 

SEEK  TALK 

ESD 

Hanscom  AFB,  MA 

Air  Force 

Navy 

S-2 

HAVE  QUICK 

ESD 

Hanscom  AFB,  MA 

Air  Force 

Navy 

S-2 

SINGARRS 

ESD 

Hanscom  AFB,  MA 

Army 

Air  Force/Navy 

S-2 

TACSI 

ESD 

Hanscom  AFB,  MA 

Air  Force 

Marine  Corps 

S-2 

GOVERNMENT  PRINTING  OFFICE  :  1982  0  -  377-652 


PROGRAM/PROJECT 

TITLE 

PROGRAM  OFFICE 
LOCATION 

JINTACCS 

ESD 

Hanscom  AFB,  MA 

CONUS-OTH 

ESD 

Hanscom  AFB,  MA 

COBRA  JUDY 

ESD 

Hanscom  AFB,  MA 

R2508 

ESD 

Hanscom  AFB,  MA 

SAFE  PROGRAMS 

ESD 

Hanscom  AFB,  MA 

BISS  PROGRAM 

ESD 

Hanscom  AFB,  MA 

LIGHT  ARMORED 

VEHICLE  PROGRAM 

TACOM 

Warren,  MI 

LEAD 

SERVICE(S) 

PARTICIPATING 

SERVICE(S) 

CLASSIFICATION 

TYPE  (SEE  FIGURE  1-1) 

Army 

Air  Force/Navy 

S-6 

Air  Force 

r 

Navy 

S-4 

« 

Air  Force 

Army  /Navy 

M-l 

Air  Force 

Navy/FAA 

M-l 

Air  Force 

Armt  (MinimaI)/ED 

M-5 

Air  Force 

Army/NavyED 

M-2 

Army 

Marine  Corp 

S-6 

60382 
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